--- Log opened Fri Mar 31 00:00:16 2017 20170331 00:04:16< vultraz_iOS> Didn't I remove that 20170331 00:04:29-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20170331 00:06:16< vultraz_iOS> celticminstrel: num_elements and contains are virtual 20170331 00:13:29< vultraz_iOS> do you have any suggestions on handling variant_iterator more cleanly 20170331 00:16:59< celticminstrel> You got the error about instantiating an abstract class because num_elements and contains are virtual? :S 20170331 00:17:25< celticminstrel> Oh wait, are you naming the ones that are pure? 20170331 00:17:41< celticminstrel> The answer to the question should've been more like "where did you use new". 20170331 00:17:51< celticminstrel> Or new variant_int. 20170331 00:19:07< celticminstrel> (And yes, you removed the intrusive_ptr stuff for some reason.) 20170331 00:19:11 * celticminstrel poke vultraz_iOS 20170331 00:19:50< vultraz_iOS> I don't use new 20170331 00:19:56< vultraz_iOS> It's emplace 20170331 00:20:01< celticminstrel> [Mar 30@7:40:47pm] vultraz_iOS: C:\Users\exodi\Documents\wesnoth\src\formula\variant.cpp|245|error: invalid new-expression of abstract class type 'game_logic::variant_int'| 20170331 00:20:17< celticminstrel> What are you emplacing into? 20170331 00:22:08< vultraz_iOS> https://pastebin.com/izT8pCki 20170331 00:23:28< celticminstrel> Uh. What. 20170331 00:23:45< celticminstrel> Ohh, I see. 20170331 00:23:55< celticminstrel> But why emplace instead of emplace_back? 20170331 00:24:10< celticminstrel> (Also this could be a place for std::iota if you wanted to use that.) 20170331 00:24:47< celticminstrel> Also, this is calling "variant(i)" which is presumably then calling "new variant_int" which leads to the error. 20170331 00:26:11< celticminstrel> Meaning that the problem lies in the variant constructor. 20170331 00:26:48< celticminstrel> If variant_int isn't supposed to be abstract, that means you forgot to implement some overridden functions in it. 20170331 00:27:12< celticminstrel> For example, if the error is that num_elements and contains are pure virtual, then you need to implement them. 20170331 00:27:22< celticminstrel> (Or declare them non-pure in variant_value_base.) 20170331 00:27:56< celticminstrel> (Which might make more sense in this case.) 20170331 00:35:30< vultraz_iOS> ah, yes 20170331 00:35:35< vultraz_iOS> all the ctors have new 20170331 00:36:32< vultraz_iOS> also, std::iota wouldn't work 20170331 00:36:38< vultraz_iOS> I'd need std::generate 20170331 00:40:08< vultraz_iOS> i'll make those functions non-pure virtual 20170331 00:40:22< vultraz_iOS> now to return to the iterator madness 20170331 00:40:30< vultraz_iOS> looks like I'll need to keep the helper class 20170331 00:41:19< vultraz_iOS> celticminstrel: can one inherit from iterator_traits? 20170331 00:41:28-!- Guest93315 [uid51591@gateway/web/irccloud.com/x-zztrwutkgwaueykt] has joined #wesnoth-dev 20170331 00:42:11-!- gfgtdf [~chatzilla@x4e3692e9.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.93 [Firefox 52.0.2/20170323105023]] 20170331 00:44:06-!- Guest93315 [uid51591@gateway/web/irccloud.com/x-zztrwutkgwaueykt] has quit [Client Quit] 20170331 00:45:55-!- ToBeFree [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev 20170331 00:47:34-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 00:52:08-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds] 20170331 01:05:27< celticminstrel> What helper class? 20170331 01:06:07< celticminstrel> What's wrong with the variant_iterator as it currently is? 20170331 01:06:35< vultraz_iOS> I don't like that it hardcodes types 20170331 01:06:37< vultraz_iOS> and only two 20170331 01:06:45< celticminstrel> IIUC, iterator_traits isn't intended for inheriting from. 20170331 01:07:12< celticminstrel> Well, those are the only iterable variant types though. 20170331 01:11:45< celticminstrel> Maybe variant_iterator could be made to somehow forward to virtual functions in variant_value_base. 20170331 01:11:59< vultraz_iOS> I was thinking just defining begin() and end() as auto + decltype(value_cast().get_iter), but apparently that cannot be done while variant_container is a template 20170331 01:12:19< celticminstrel> Obviously. 20170331 01:12:30< vultraz_iOS> very sad 20170331 01:12:40< celticminstrel> And unavoidable. 20170331 01:13:07< celticminstrel> But yeah you could probably somehow forward to variant_value_base virtual functions. 20170331 01:13:16< celticminstrel> Not entirely certain how that would work though. 20170331 01:13:45< vultraz_iOS> well, that's one function that would be pure virtual 20170331 01:14:22< celticminstrel> BTW, there's actually a potentially major problem with variant_iterator. 20170331 01:14:43< celticminstrel> Oh wait, maybe not? 20170331 01:15:05< celticminstrel> I guess an iterator loop over a scalar variant would just be a no-op since begin() == end(). 20170331 01:15:09< celticminstrel> Never mind then! 20170331 01:15:17< vultraz_iOS> :( 20170331 01:15:20< celticminstrel> Though that does still have something weird. 20170331 01:15:32< celticminstrel> (Why sadface?) 20170331 01:15:49< vultraz_iOS> I was hoping for an excuse to get rid of it 20170331 01:16:09< celticminstrel> The weird thing is that an iterator-based loop over a scalar variant executes 0 times, but a regular for-loop over a scalar variant would execute once since num_elements() is 1. 20170331 01:16:15< celticminstrel> Get rid of what exactly? 20170331 01:16:35< vultraz_iOS> or at least, refactor it 20170331 01:16:38< vultraz_iOS> the iterator class 20170331 01:16:47< celticminstrel> Okay sure refactor it I guess? 20170331 01:18:09< celticminstrel> I assume it's used in places so getting rid of it might be a bit much. 20170331 01:19:55< vultraz_iOS> or I could always expose the container 20170331 01:20:01< celticminstrel> ?? 20170331 01:20:26< vultraz_iOS> iterate over as_list or as_map 20170331 01:20:40< celticminstrel> Pretty sure the point of it is so that you can treat those the same. 20170331 01:20:59< vultraz_iOS> true, true... 20170331 01:22:45 * celticminstrel is trying to imagine how it could be implemented by storing a pointer to the variant_value_base being iterated and forwarding to virtual functions in that class. 20170331 01:24:24< celticminstrel> If you did that, it could be extended to allow iterating over a formula_callable, too. 20170331 01:24:47< celticminstrel> (Using formula_callable::get_inputs(), most likely.) 20170331 01:26:03< celticminstrel> It seems like it would require an opaque value though. 20170331 01:35:40< celticminstrel> The design I'm thinking of goes something like this... 20170331 01:37:07< celticminstrel> variant_value_base has a number of private virtual functions - "any get_begin()", "any get_end()", "variant get_this(any)", "any get_next(any)", "any get_prev(any)". 20170331 01:37:25< celticminstrel> It declares variant_iterator as a friend class. 20170331 01:38:06< celticminstrel> variant_iterator stores two things - a pointer to the variant_value_base, and the "any" returned from either get_begin() or get_end(). 20170331 01:39:08< celticminstrel> It uses get_next() to implement the ++ operators, get_prev to implement the -- operators, get_this to implement the * operator. 20170331 01:39:35< celticminstrel> Equality of the iterator would be equality of its two components. 20170331 01:39:47< celticminstrel> Assignment of the iterator would be assignment of its two components. 20170331 01:39:59< celticminstrel> And uh... that's about it, I guess. 20170331 01:40:39< celticminstrel> Well, that method makes it uncertain how to do the constructors, though. 20170331 01:56:57-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20170331 01:57:03-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20170331 02:50:32-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20170331 02:50:38-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20170331 02:51:20-!- ToBeFree [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity] 20170331 03:35:26-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 03:41:04-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds] 20170331 03:53:27-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev 20170331 04:00:03-!- Kwandulin [~Kwandulin@p200300760F3E7D6E410FE63E8C325AA6.dip0.t-ipconnect.de] has joined #wesnoth-dev 20170331 04:17:45-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity] 20170331 04:28:01-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV] 20170331 04:32:49-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev 20170331 04:44:34< vultraz_iOS> ya know, I'll give mordante credit. The guy *really* knew metaprogramming. 20170331 04:44:50< vultraz_iOS> though I think iceiceice knows it more 20170331 04:44:58< vultraz_iOS> if his utility repos are anything to go by 20170331 04:57:57< celticminstrel> Why are you bringing this up all of a sudden? 20170331 04:58:37< vultraz_iOS> well, because I'm working with templates and stuff 20170331 05:03:12-!- JyrkiVesterinen [~JyrkiVest@87-100-220-162.bb.dnainternet.fi] has joined #wesnoth-dev 20170331 05:08:19< vultraz_iOS> let's see if I can remove some of these operators... 20170331 05:10:01< vultraz_iOS> nope 20170331 05:26:41< vultraz_iOS> what's the difference between const T::iterator and T::const_iterator? 20170331 05:31:13< celticminstrel> The same as the difference between T*const and const T* 20170331 05:31:29< vultraz_iOS> I see 20170331 05:31:39< celticminstrel> The first is a const iterator - it always points to the same place, but the thing it points to can be changed. 20170331 05:31:48< celticminstrel> This makes it similar to a non-const reference. 20170331 05:32:11< celticminstrel> The second is an iterator-to-const - it can be changed to point to different things, but the thing it points to cannot be changed. 20170331 05:37:38-!- celticminstrel is now known as celmin|sleep 20170331 06:04:17-!- JyrkiVesterinen [~JyrkiVest@87-100-220-162.bb.dnainternet.fi] has quit [Quit: .] 20170331 06:11:28-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20170331 06:11:34-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20170331 06:31:02-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 06:35:46-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 264 seconds] 20170331 06:41:45-!- JyrkiVesterinen [~JyrkiVest@85-76-72-223-nat.elisa-mobile.fi] has joined #wesnoth-dev 20170331 06:45:47-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20170331 06:55:29-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!] 20170331 07:10:00-!- atarocch [~atarocch@93.56.160.28] has joined #wesnoth-dev 20170331 07:11:25-!- Kwandulin [~Kwandulin@p200300760F3E7D6E410FE63E8C325AA6.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20170331 07:14:42-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev 20170331 08:04:46-!- prkc [~prkc@d5.85.7a9f.ip4.static.sl-reverse.com] has quit [Ping timeout: 256 seconds] 20170331 08:19:20-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 08:20:33-!- prkc [~prkc@46.166.188.210] has joined #wesnoth-dev 20170331 08:23:35-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 240 seconds] 20170331 08:34:57-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20170331 08:35:04-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20170331 09:08:07-!- JyrkiVesterinen [~JyrkiVest@85-76-72-223-nat.elisa-mobile.fi] has quit [Quit: .] 20170331 09:37:04-!- JyrkiVesterinen [~JyrkiVest@85-76-72-223-nat.elisa-mobile.fi] has joined #wesnoth-dev 20170331 10:07:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 10:12:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 268 seconds] 20170331 11:00:06-!- Alkenrinnstet [~alkenrinn@42.61.217.253] has joined #wesnoth-dev 20170331 11:26:47-!- Alkenrinnstet [~alkenrinn@42.61.217.253] has quit [Read error: Connection reset by peer] 20170331 11:27:08-!- Alkenrinnstet [~alkenrinn@42.61.217.253] has joined #wesnoth-dev 20170331 11:33:21-!- iwaim__ [~iwaim@124.146.179.10] has quit [Ping timeout: 260 seconds] 20170331 11:46:02-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 258 seconds] 20170331 11:46:37-!- iwaim__ [~iwaim@rasteenie.alib.jp] has joined #wesnoth-dev 20170331 11:52:07-!- Kwandulin [~Kwandulin@p200300760F3E7D6E984DC8B06CCCAD0B.dip0.t-ipconnect.de] has joined #wesnoth-dev 20170331 11:55:59-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 12:00:24-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds] 20170331 12:23:04-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev 20170331 13:37:00-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009] 20170331 14:04:19-!- Kwandulin [~Kwandulin@p200300760F3E7D6E984DC8B06CCCAD0B.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20170331 14:37:33-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 240 seconds] 20170331 14:48:39-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev 20170331 14:55:47-!- DeFender1031 [~DeFender1@217.132.17.168] has quit [Quit: I'm not back now.] 20170331 15:06:05-!- celmin|sleep is now known as celticminstrel 20170331 15:12:55-!- Kwandulin [~Kwandulin@p200300760F3E7D6EB015C256830CC5DB.dip0.t-ipconnect.de] has joined #wesnoth-dev 20170331 15:19:50-!- JyrkiVesterinen [~JyrkiVest@85-76-72-223-nat.elisa-mobile.fi] has quit [Quit: .] 20170331 15:25:37-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 15:30:14-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev 20170331 15:36:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20170331 15:36:43-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 15:49:29-!- JyrkiVesterinen [~JyrkiVest@89-166-102-64.bb.dnainternet.fi] has joined #wesnoth-dev 20170331 15:58:10-!- RatArmy_ [~ratarmy@om126204192100.6.openmobile.ne.jp] has quit [Read error: Connection reset by peer] 20170331 16:00:14< Kwandulin> zookeeper: https://forums.wesnoth.org/viewtopic.php?f=9&p=610181#p610181 20170331 16:02:42< zookeeper> Kwandulin, very nice, and the shoes are pretty cool. the main thing that seems off is that the non-sword forearm is pretty uniformly thick and formless, no clear wrist etc 20170331 16:03:09< Kwandulin> hehe, hellboy 20170331 16:04:01< zookeeper> kinda :p 20170331 16:06:36< Kwandulin> alright, made the arm a bit thinner and more defined 20170331 16:08:26< zookeeper> yeah, it's better 20170331 16:11:28< zookeeper> i know pixeling hands is really tricky, but it would be nice if there was a bit more definition to the non-sword hand in the final version so that one could tell what position it's actually in. whether it's a fist or an open palm, which way is it oriented, is he just using it for balance or resting it on his beltt, and so on. 20170331 16:12:13< zookeeper> other than that, doesn't seem to be much to tweak except the face 20170331 16:17:42< zookeeper> oh and the TC thing on his waist should probably be lower, i presume the intent is for it to be closer to the waist 20170331 16:18:08< zookeeper> i mean... it's not on his waist now, more like halfway up his chest. but i presume it's supposed to be on the waist :p 20170331 16:20:56-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev 20170331 16:27:08< Kwandulin> ^ updated post 20170331 16:30:56< celticminstrel> And now, I have flooded vultraz_iOS's inbox with 48 comments on his pull request! \o/ 20170331 16:34:48< zookeeper> Kwandulin, i'll give some further feedback later, kinda busy right now 20170331 16:35:09-!- Nagu [5b9db676@gateway/web/freenode/ip.91.157.182.118] has joined #wesnoth-dev 20170331 16:35:28< Kwandulin> sure 20170331 17:04:41-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20170331 17:05:44-!- Kwandulin [~Kwandulin@p200300760F3E7D6EB015C256830CC5DB.dip0.t-ipconnect.de] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 20170331 17:06:56-!- Kwandulin [~Kwandulin@p200300760F3E7D6EB015C256830CC5DB.dip0.t-ipconnect.de] has joined #wesnoth-dev 20170331 17:09:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 17:17:45-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity] 20170331 17:37:21-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20170331 17:42:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 17:45:23-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev 20170331 17:47:41< vultraz_iOS> celticminstrel: so, about that nullptr for callable mutable... 20170331 17:47:49< celticminstrel> Oh hi. 20170331 17:48:08< vultraz_iOS> celticminstrel: I looked and looked in the old code, and I can't seem to find a place where callable_mutable is actually assigned anything :| 20170331 17:48:42< celticminstrel> Hmm. 20170331 17:49:49< vultraz_iOS> celticminstrel: replied to a bunch of stuff 20170331 17:50:14< celticminstrel> And variant doesn't declare any friend classes, so it can't be accessed from outside. 20170331 17:50:22< celticminstrel> I guess it was a half-finished thing that was never used. 20170331 17:50:30< vultraz_iOS> you seem especially curious about why the serialize_to_string API was changed. 20170331 17:50:38< celticminstrel> I don't suppose my PR used it? 20170331 17:50:49< celticminstrel> mutable_callable I mean. 20170331 17:50:54< vultraz_iOS> tl'dr: old impl used += many many many times 20170331 17:51:05< celticminstrel> Yes, and? 20170331 17:51:08< vultraz_iOS> new impl uses a stringstream and returns the completed string only 20170331 17:51:12< vultraz_iOS> more efficient 20170331 17:51:20< celticminstrel> Well yes, that's good, but it's not what I saw...? 20170331 17:51:32< celticminstrel> Maybe I wasn't looking closely enough. 20170331 17:51:35< vultraz_iOS> what do you mean? 20170331 17:51:44< vultraz_iOS> that's exactly what I did :/ 20170331 17:51:45< celticminstrel> Let me look at all your other replies first. 20170331 17:57:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev 20170331 17:57:57-!- Kwandulin [~Kwandulin@p200300760F3E7D6EB015C256830CC5DB.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer] 20170331 17:59:36< celticminstrel> Anyway, if you're going the stringstream route, I think it'd make the most sense if all the serialize functions take the stringstream (or rather, an std::ostream) as a parameter; then variant::serialize_to_string simply constructs an ostringstream and passes that on to value_->serialize(). 20170331 17:59:42< celticminstrel> Or something along those lines, anyway. 20170331 18:01:33< vultraz_iOS> I can do that 20170331 18:01:49< vultraz_iOS> first off, I think I need to decide what to do about the mutable callable thing 20170331 18:02:05< vultraz_iOS> it just seems to be used as a value for try_convert :/ 20170331 18:03:28< vultraz_iOS> actually, first i need to see why it crashes at start 20170331 18:03:37< vultraz_iOS> it's weird 20170331 18:03:39< JyrkiVesterinen> Regarding string conversion, I recommend overloading operator<< if there is a reasonable default conversion. 20170331 18:03:41< JyrkiVesterinen> http://stackoverflow.com/a/1549937/6559805 20170331 18:04:08< vultraz_iOS> it doesn't happen every time, but it very much seems there an uninitialized value somewhee 20170331 18:05:50< vultraz_iOS> celticminstrel: btw, according to this http://en.cppreference.com/w/cpp/memory/shared_ptr/operator_cmp shared_ptr == shared_ptr compares the values of .get() 20170331 18:06:30< JyrkiVesterinen> Well, they still compare pointers. Remember that .get() returns a pointer. 20170331 18:06:53< vultraz_iOS> oh, and he's saying it should compare value 20170331 18:10:52< vultraz_iOS> looks like *value_ == v.value_ is what I want 20170331 18:14:44-!- midzer [~quassel@p5B05188A.dip0.t-ipconnect.de] has quit [Ping timeout: 258 seconds] 20170331 18:32:04< celticminstrel> vultraz_iOS: I said exactly what you wnt in the comment, didn't I? 20170331 18:32:14< celticminstrel> ^want 20170331 18:32:36< vultraz_iOS> no, the op functions take a base ptr 20170331 18:32:59< vultraz_iOS> so I need to do *value_ == v.value_ not *v.value_ 20170331 18:33:09< celticminstrel> You need two * 20170331 18:33:22< celticminstrel> Wait what? 20170331 18:33:40< celticminstrel> Change the op functions then! 20170331 18:34:02< celticminstrel> Op functions should never take a pointer unless they're comparing the pointer. 20170331 18:34:29< vultraz_iOS> they take a std::shared_ptr; 20170331 18:34:36< celticminstrel> Give them a reference instead. 20170331 18:35:03< vultraz_iOS> needs to be a pointer of some sort so I can cast 20170331 18:35:08< vultraz_iOS> either smart or raw 20170331 18:35:10< celticminstrel> No it doesn't. 20170331 18:35:19< vultraz_iOS> oh right 20170331 18:35:23< vultraz_iOS> I forgot 20170331 18:35:27< celticminstrel> dynamic_cast works on point pointers and references. 20170331 18:35:31< vultraz_iOS> yeah 20170331 18:35:32< celticminstrel> ^both not point 20170331 18:36:10< vultraz_iOS> so make them take variant_value_base& not std::shared_ptr? 20170331 18:36:14< celticminstrel> Yes. 20170331 18:38:14< celticminstrel> JyrkiVesterinen: Re overloading <<, IMO it's not really clear which of the three string representations it should use. 20170331 18:38:25< celticminstrel> I mean, string_cast is obviously out, but debug vs serialize? 20170331 18:39:22< vultraz_iOS> still waiting to hear what you think i should do about the mutable callable 20170331 18:39:27< celticminstrel> debug can output any value, but will elide duplicate references; serialize cannot output non-serializable formula callables. 20170331 18:42:43< celticminstrel> vultraz_iOS: Well, I'm not quite sure. It's clear that the set_var() @FL function does rely on it somehow. 20170331 18:43:16< vultraz_iOS> but it would only never be a nullptr :/ 20170331 18:43:26< vultraz_iOS> i dont understand how it even worked 20170331 18:43:43< celticminstrel> Oh! 20170331 18:43:47< celticminstrel> I get why it worked. 20170331 18:43:55< celticminstrel> It was a union. 20170331 18:44:15< celticminstrel> So if you assign to callable_ and then read from mutable_callable_, it works. 20170331 18:44:22< vultraz_iOS> I see 20170331 18:44:45< vultraz_iOS> you don't recommend a local union do you :P 20170331 18:44:51-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20170331 18:44:56< celticminstrel> I'm not really in favour of dropping all the consts on the formula_callables, but... unfortunately that might actually be the best option. 20170331 18:45:27-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 18:45:42< celticminstrel> Then you wouldn't need the mutable_callable() function because the callable is always mutable. 20170331 18:45:58< celticminstrel> The reason I'm not in favour is that variants are supposed to be immutable. 20170331 18:46:19< celticminstrel> But then... they're supposed to be immutable from the viewpoint of WFL code, and that would still be the case. 20170331 18:46:37< celticminstrel> And with try_convert() they're already technically mutable... 20170331 18:46:55< celticminstrel> Yeah, I think I'd just suggest using non-const formula_callable* everywhere in the variant. 20170331 18:47:04< vultraz_iOS> OK 20170331 18:49:44< vultraz_iOS> another thing I should do is make variant take more stuff by referencee 20170331 18:49:47< vultraz_iOS> not pointer 20170331 18:49:50-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Ping timeout: 260 seconds] 20170331 18:49:51< vultraz_iOS> or at least, the containers 20170331 18:50:34< celticminstrel> Yes, the containers can be taken by reference. Note that it does still need to copy their contents either way, though. 20170331 18:51:12< celticminstrel> I've just replied to more of your replies. 20170331 18:54:04-!- midzer [~quassel@p5B0511DF.dip0.t-ipconnect.de] has joined #wesnoth-dev 20170331 19:00:08-!- trewe [~trewe@2001:8a0:d117:d01:9f8c:6242:4a7b:9a6] has joined #wesnoth-dev 20170331 19:00:57-!- Kwandulin [~Kwandulin@p200300760F3E7D6E3D5AE2B8B1183D5C.dip0.t-ipconnect.de] has joined #wesnoth-dev 20170331 19:01:37< vultraz_iOS> gahh function_table.cpp 20170331 19:01:41< vultraz_iOS> so messy 20170331 19:02:24< celticminstrel> Try to ignore it. :| 20170331 19:02:41< celticminstrel> Focus! 20170331 19:02:52< celticminstrel> Of course you can make it less messy later. 20170331 19:03:03< celticminstrel> Like, after this refactor is finished? 20170331 19:03:15< vultraz_iOS> im removing those duplicate conversion functions 20170331 19:03:17< vultraz_iOS> using the class ones 20170331 19:03:21< celticminstrel> Say what? 20170331 19:03:39< vultraz_iOS> try_convert_variant 20170331 19:03:44< celticminstrel> Ohhh, sure. 20170331 19:03:49< celticminstrel> I did suggest that didn't I. 20170331 19:03:52< vultraz_iOS> indeed 20170331 19:04:26< celticminstrel> BTW, you never commented on my outline for a possible generic variant_iterator design. 20170331 19:04:40< vultraz_iOS> eh? 20170331 19:04:42< vultraz_iOS> where? 20170331 19:04:48< celticminstrel> Yesterday sometime. 20170331 19:05:30< celticminstrel> About 18 hours ago I think. 20170331 19:06:03< vultraz_iOS> oh 20170331 19:06:05< vultraz_iOS> what was it again? 20170331 19:06:10< celticminstrel> Sigh. 20170331 19:06:15< celticminstrel> Okay I'll PM you the log. 20170331 19:07:36< celticminstrel> Changed my mind. Have a paste that expires in 10 minutes instead. https://pastebin.com/zReF8Scz 20170331 19:08:13< celticminstrel> Mostly the block of me speaking at the bottom, but I decided to give all the context too. 20170331 19:08:24< vultraz_iOS> huh 20170331 19:08:25< vultraz_iOS> hmmm 20170331 19:08:35< vultraz_iOS> ill have to consider further 20170331 19:08:37< celticminstrel> It was just an idea. 20170331 19:08:43< celticminstrel> Not a recommendation. 20170331 19:08:54< celticminstrel> BTW, by "any" I mean boost::any. 20170331 19:13:11 * vultraz_iOS ponders if he needs dynamic_pointer_cast at all, of he can use reference casting everywhere 20170331 19:13:53-!- JyrkiVesterinen [~JyrkiVest@89-166-102-64.bb.dnainternet.fi] has quit [Quit: .] 20170331 19:14:28< vultraz_iOS> thoughts? 20170331 19:15:05< celticminstrel> Reference casting throws std::bad_cast if the cast fails. 20170331 19:15:34< vultraz_iOS> right 20170331 19:15:43< celticminstrel> So if it's a situation where you expect failure to be likely and you want your own error message, it's often better to pointer cast instead. 20170331 19:16:02< celticminstrel> Even if you have a reference, you can easily pointer cast by taking its address. 20170331 19:16:34-!- Alkenrinnstet [~alkenrinn@42.61.217.253] has quit [Ping timeout: 264 seconds] 20170331 19:16:42< vultraz_iOS> but definitely ref cast for the operators? 20170331 19:17:25< celticminstrel> Well, what's supposed to happen if the cast fails? 20170331 19:17:58< vultraz_iOS> well, it throws 20170331 19:18:16< vultraz_iOS> type_error 20170331 19:18:21< celticminstrel> So if you ref-cast you need to catch bad_cast and throw a different exception instead. 20170331 19:18:30< vultraz_iOS> yes 20170331 19:18:46< vultraz_iOS> you just said earlier the ops shouldn't take a shared_ptr :/ 20170331 19:18:54< celticminstrel> Yes, they shouldn't. 20170331 19:19:05< celticminstrel> If you use a non-operator function instead though, it could take a shared_ptr. 20170331 19:19:06-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Read error: Connection timed out] 20170331 19:19:19< celticminstrel> Like, call it equals() instead of operator==(), less_equal() instead of operator<=() 20170331 19:19:23< celticminstrel> Or some such. 20170331 19:19:26-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev 20170331 19:20:08< celticminstrel> variant_value_base is only really intended for internal use in the variant anyway, right? So it doesn't really need operators. 20170331 19:21:31< vultraz_iOS> true 20170331 19:21:37< vultraz_iOS> but it makes it obvious what it's for 20170331 19:21:48< vultraz_iOS> and is good for comparing values 20170331 19:21:50< celticminstrel> So does calling it "equals". 20170331 19:25:54< celticminstrel> IMO it's not a great idea to have virtual operators, but that might be just me... 20170331 19:34:57< zookeeper> Kwandulin, i'll try to come up with an edit to the hand, it's really hard to try to explain in text what i think is wrong with it 20170331 19:36:02< Kwandulin> sure 20170331 19:56:30-!- trewe [~trewe@2001:8a0:d117:d01:9f8c:6242:4a7b:9a6] has quit [Quit: quit] 20170331 20:00:09< vultraz_iOS> if(res != res) return variant(); 20170331 20:00:13< vultraz_iOS> ok this doesn't make sense 20170331 20:00:17< vultraz_iOS> if res is not itself? 20170331 20:00:18< vultraz_iOS> :/ 20170331 20:00:58< celticminstrel> It's because NaN violates orderability. 20170331 20:01:16< celticminstrel> NaN is not equal to itself, so n != n is one way of detecting NaN. 20170331 20:01:24< celticminstrel> There's also an isnan() function though. 20170331 20:06:34< vultraz_iOS> NaN? 20170331 20:06:39< vultraz_iOS> Not a number! 20170331 20:06:40< vultraz_iOS> . 20170331 20:06:42< vultraz_iOS> ? 20170331 20:06:52< vultraz_iOS> Wow I cannot type punctuation 20170331 20:06:54< celticminstrel> Yes. 20170331 20:13:29-!- louis94 [~~louis94@163.50-65-87.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev 20170331 20:16:35< loonycyborg> wow no wonder that it's called not a number 20170331 20:16:45< loonycyborg> considering it's not equal to itself 20170331 20:17:26< zookeeper> Kwandulin, eh, i got side-tracked on my first attempt and changed the hand position so that... now he looks like he's thoughtfully stroking his hair, i guess? https://www.dropbox.com/s/9uxf850ojvyx3pw/kaleh_hand_1.png?dl=0 20170331 20:18:27< zookeeper> i'm gonna make another but i figured i'd show that anyway since i think it worked out okay technically :p 20170331 20:18:40< Kwandulin> Looks like a hand 20170331 20:19:10< Kwandulin> Also, he might be grabbing a necklace or something 20170331 20:21:26< zookeeper> if only he had a baldric or similar 20170331 20:21:54< zookeeper> wait, he has to have since that quiver has to be carried on something :P 20170331 20:22:26< Kwandulin> there we go . . . 20170331 20:22:53< zookeeper> so, i dunno, do you want to go with that design after all? 20170331 20:24:01< Kwandulin> sure, what's left to be done beside the baldric? 20170331 20:27:27< zookeeper> i guess cleaning up the parts of the TC waist thing i hastily filled in, and the face 20170331 20:30:06< zookeeper> oh and i'll move the new forearm 1px to the left 20170331 20:30:13-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 20:30:26< zookeeper> unless it's faster for you to just do it yourself 20170331 20:30:43< Kwandulin> just the forearm? 20170331 20:31:05< zookeeper> well the hand too of course 20170331 20:31:09< Kwandulin> yeah, done 20170331 20:32:14< zookeeper> okay, cool. my edit obscured the buttons of the shirt/whatever and the elbow looked a bit weird, so 1px to the left is better 20170331 20:33:07< zookeeper> the ears don't seem to be using the same skin tones 20170331 20:34:01< Kwandulin> oh, yes, that's right. just an oversight 20170331 20:36:13< zookeeper> they are both pretty much the size of a lvl3 though, not sure if that's a problem 20170331 20:36:52< Kwandulin> i personally find it strange, when a "hero" is so small 20170331 20:37:13< Kwandulin> there's a post of jetrel regarding biggerism somewhere on the forums 20170331 20:37:52< zookeeper> "creeping biggerism is good"? :> 20170331 20:38:43< zookeeper> i mean, i don't think a hero is "small" if they're "not bigger than a lvl3 general" 20170331 20:39:33< Kwandulin> it was some post about warcraft if i remember correctly 20170331 20:39:47< Kwandulin> anyway, there's some options to reduce the size of kaleh, if needed 20170331 20:40:32< zookeeper> or just nym; she's about 2px taller than kaleh as it is (depending on where you measure) 20170331 20:45:58< Kwandulin> https://www.dropbox.com/s/peb8kl6z0vcpb8q/nym.png?dl=0 reduced height (head to toe, ignoring bow) by 2px 20170331 20:46:26< Kwandulin> https://www.dropbox.com/s/sbch3n69eo4ixjr/kaleh.png?dl=0 some adjustments to skirt and face 20170331 20:46:32< Kwandulin> not sure what you want regarding the face 20170331 20:49:08-!- louis94 [~~louis94@163.50-65-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 260 seconds] 20170331 20:50:37< zookeeper> uh... the other forearm 20170331 20:51:03< Kwandulin> uh-oh 20170331 20:52:40< zookeeper> also i don't think the white'ish eyes work on a sprite, they probably look spooky in an unintended way in-game 20170331 20:54:09< zookeeper> and the last edit did improve kaleh's face in the sense that now it's clear where his other eye is. i think there's still some little pixel adjustments one could make to make the face better overall, but i don't have any specific suggestions right now 20170331 20:59:08< Kwandulin> https://www.dropbox.com/s/d93rrz6uj0a5ipf/kaleh.png?dl=0 https://www.dropbox.com/s/zenvmqg3nmja9d7/nym.png?dl=0 fixed forearm. yeah the eyes probably need some more work. looks rather demonic to me, now 20170331 21:02:35< zookeeper> did you leave the buttons out on purpose? 20170331 21:04:06< Kwandulin> somewhat, yeah, they should have been visible before moving the forearm to the left, but there weren't buttons anymore 20170331 21:04:21< Kwandulin> the darkred pixels should be the buttons then, i'd imagine 20170331 21:06:36-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20170331 21:20:35< Kwandulin> anyway, ill take care of those tomorrow 20170331 21:20:41< zookeeper> sure, great 20170331 21:20:50-!- Kwandulin [~Kwandulin@p200300760F3E7D6E3D5AE2B8B1183D5C.dip0.t-ipconnect.de] has quit [Quit: Miranda IM! Smaller, Faster, Easier. http://miranda-im.org] 20170331 21:37:34-!- Nagu [5b9db676@gateway/web/freenode/ip.91.157.182.118] has quit [Quit: Page closed] 20170331 21:56:56-!- louis94 [~~louis94@163.50-65-87.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev 20170331 22:03:04-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20170331 22:20:38< vultraz_iOS> celticminstrel: using non-const formula_callable* causes errors in formula_callable... :/ 20170331 22:21:33< celticminstrel> Yaaaaaay... what sort of errors? 20170331 22:23:02< vultraz_iOS> ..\..\src\formula\callable.hpp|47|error: invalid conversion from 'const game_logic::formula_callable*' to 'game_logic::formula_callable*' [-fpermissive]| 20170331 22:23:14< vultraz_iOS> all it is is variant(this)... 20170331 22:24:15< celticminstrel> Oh. 20170331 22:24:43< celticminstrel> BTW, is has_self ever false? 20170331 22:25:19< vultraz_iOS> has_self? 20170331 22:25:48< vultraz_iOS> ah 20170331 22:25:53< celticminstrel> Seems like the answer is yes... 20170331 22:26:13< celticminstrel> map_formula_callable apparently? 20170331 22:26:28< celticminstrel> formula_variant_callable_with_backup too. 20170331 22:26:39< celticminstrel> And whatever's on line 558 of formula.cpp. 20170331 22:27:25-!- louis94 [~~louis94@163.50-65-87.adsl-dyn.isp.belgacom.be] has quit [Ping timeout: 260 seconds] 20170331 22:27:48< celticminstrel> Okay, so, it wouldn't be right to make query_value() non-const though... 20170331 22:28:26-!- louis94 [~~louis94@163.50-65-87.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev 20170331 22:29:26-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV] 20170331 22:33:18-!- Greg-Boggs [~greg_bogg@173.240.241.83] has quit [Remote host closed the connection] 20170331 22:35:16-!- Greg-Boggs [~greg_bogg@173.240.241.83] has joined #wesnoth-dev 20170331 22:37:11-!- mjs-de [~mjs-de@x4e30e8a0.dyn.telefonica.de] has joined #wesnoth-dev 20170331 22:38:00< matthiaskrgr> 22:01 < celticminstrel> NaN is not equal to itself, so n != n is one way of detecting NaN. 20170331 22:38:07< matthiaskrgr> I think the UBsan should be able to detect NANs 20170331 22:42:01< celticminstrel> Why is this relevant? 20170331 22:42:20< celticminstrel> And I doubt it could anyway. At least in this case. 20170331 22:42:38< celticminstrel> Since it's calcluations based on user code. 20170331 22:44:33< matthiaskrgr> well, nevermind .... 20170331 22:45:53< vultraz_iOS> I changed it to use std::isnan 20170331 22:46:22< celticminstrel> Fine by me. 20170331 22:48:54-!- atarocch [~atarocch@93.56.160.28] has quit [Remote host closed the connection] 20170331 22:50:50-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev 20170331 23:02:46-!- louis94 [~~louis94@163.50-65-87.adsl-dyn.isp.belgacom.be] has quit [Read error: Connection reset by peer] 20170331 23:04:54-!- louis94 [~~louis94@163.50-65-87.adsl-dyn.isp.belgacom.be] has joined #wesnoth-dev 20170331 23:04:59-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev 20170331 23:09:59-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20170331 23:10:07-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20170331 23:11:57-!- mjs-de [~mjs-de@x4e30e8a0.dyn.telefonica.de] has quit [Remote host closed the connection] 20170331 23:14:28-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy] 20170331 23:20:37< vultraz_iOS> celticminstrel: so, what do you advise 20170331 23:20:39< vultraz_iOS> const_cast 20170331 23:20:39< vultraz_iOS> ? 20170331 23:25:39-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection] 20170331 23:25:48-!- janebot [~Gambot@grickit.us] has joined #wesnoth-dev 20170331 23:25:57-!- janebot [~Gambot@grickit.us] has quit [Changing host] 20170331 23:25:57-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev 20170331 23:38:38-!- Appleman1234 [~Appleman1@pl10188.ag1212.nttpc.ne.jp] has quit [Ping timeout: 256 seconds] 20170331 23:38:53< vultraz_iOS> celticminstrel: btw, you also said that the base should have a value 20170331 23:39:08< vultraz_iOS> but if is_null() it never accesses any value 20170331 23:54:22-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 264 seconds] 20170331 23:55:00-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection] 20170331 23:57:03< celticminstrel> vultraz_iOS: Huh? 20170331 23:57:46< celticminstrel> As for the constness... I generally wouldn't advise const_cast, but... that's effectively what it was doing already, so sure, I guess. 20170331 23:58:38< celticminstrel> Use const_cast in variant, not in formula_callable. 20170331 23:58:52< celticminstrel> So... keep the constructor that takes a const formula_callable* --- Log closed Sat Apr 01 00:00:33 2017