--- Log opened Sun Jan 14 00:00:42 2018
20180114 00:00:46-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit []
20180114 00:15:27-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180114 00:15:35-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180114 00:17:34< vultraz> celticminstrel: poke
20180114 00:18:54< celticminstrel> ?
20180114 00:19:02< celticminstrel> Is this about the question from earlier?
20180114 00:19:08< celticminstrel> Not that I remember what it was...
20180114 00:19:43< vultraz> do you think I should restore matches_name
20180114 00:20:24< vultraz> ie, instead of looping through the names, just do if(handler.matches_name(standardized_event_id)) { func
20180114 00:20:47< vultraz> The consensus seems to be it's more efficient
20180114 00:21:23< celticminstrel> Marginally, but yes; it's the same order, O(n), but the coefficient is slightly lower. Is it enough to matter? I have no idea.
20180114 00:21:26-!- irker768 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20180114 00:21:26< irker768> wesnoth/wesnoth:master pentarctagon 4a4df11eaa Renames the Khalifate to Dunefolk. AppVeyor: All builds passed
20180114 00:21:42< celticminstrel> If you restore it, I think the better reason is not efficiency but rather compatibility?
20180114 00:21:53< vultraz> compatibility with what
20180114 00:22:23< celticminstrel> By replacing underscores with spaces, event names that previously worked might work no longer, depending on when exactly the substitution takes place.
20180114 00:22:45< vultraz> I only standardize event names with no variables
20180114 00:22:58< celticminstrel> Even if you took care to ensure that the underscore substitution occurs after the variable substitution, it's still more fragile against further code changes IMO.
20180114 00:22:59< vultraz> if the name has none to begin with, it happens when the handler is created
20180114 00:23:08< vultraz> if it does, it happens after standardization
20180114 00:23:15< vultraz> er
20180114 00:23:19< vultraz> after substitution
20180114 00:23:20< vultraz> sorry
20180114 00:23:22< celticminstrel> And if you only standardize event names with no variables, doesn't it semi-defeat the point of standardizing?
20180114 00:23:39< celticminstrel> Because then some names (those that had variables) still won't be standardized.
20180114 00:23:49< vultraz> are you saying you think there should be no pre-standardization at all
20180114 00:24:02< celticminstrel> Pre-standardization?
20180114 00:24:22< vultraz> "if the name has none to begin with, it happens when the handler is created"
20180114 00:24:39< vultraz> I store standardized names (the ones without variables) in the config.
20180114 00:24:47< vultraz> when the handler is created
20180114 00:25:04< vultraz> the ones WITH variables are untouched
20180114 00:25:15< vultraz> ie, a standardized version is never written back to the config
20180114 00:25:32< vultraz> since the standardization happens at match check time
20180114 00:26:20< vultraz> the reason I introduced that was to simplify by-variable and by-name lookup...
20180114 00:26:32< vultraz> but come to think of it, I might not even need any of those lookups anymore
20180114 00:26:35< vultraz> hmmmm
20180114 00:26:40< celticminstrel> So you're standardizing twice?
20180114 00:26:47< vultraz> once
20180114 00:27:03< vultraz> just happens at different times depending if the name has variables or not
20180114 00:27:20< vultraz> ie, name=turn 1, turn $foo
20180114 00:27:22< vultraz> becomes
20180114 00:27:29< vultraz> name=turn_1, turn $foo
20180114 00:27:34< vultraz> then during match checking, we test
20180114 00:27:38< vultraz> name == turn_1
20180114 00:27:53< vultraz> name == standardize(substitute("turn $foo))
20180114 00:28:21< vultraz> which goes something like "turn $foo" -> "turn 2" -> "turn_2"
20180114 00:28:31< celticminstrel> This seems more complicated than simply having a custom match function...?
20180114 00:28:31< vultraz> and is then compared with ==
20180114 00:28:39< vultraz> perhaps
20180114 00:28:39< celticminstrel> BTW, are event names used as keys in a map?
20180114 00:28:44< vultraz> yes
20180114 00:28:51< vultraz> but I might not even need those maps anymore
20180114 00:28:54< vultraz> and might remove them
20180114 00:29:10< celticminstrel> Well, if you do need the maps, then rather than match_name you'd need an operator< which considers space and underscore to be equal.
20180114 00:29:24< vultraz> they were only used as map keys when they did not have variables and were standardized before being used as keys
20180114 00:29:25< celticminstrel> (ie, ' ' < '_' is false and '_' < ' ' is false.)
20180114 00:29:37< vultraz> so we don't need that
20180114 00:31:14< vultraz> cleanup needs to be done
20180114 00:31:22< vultraz> what I'm wondering now is if I should restore matches_name
20180114 00:31:54< vultraz> you said == is less efficient in the common case, yes?
20180114 00:32:05< celticminstrel> ???
20180114 00:32:10< celticminstrel> Ohh.
20180114 00:32:23< celticminstrel> Are you talking about where I said "in the worst case"?
20180114 00:32:29< vultraz> yes
20180114 00:32:37< vultraz> you also said the worst case is common
20180114 00:32:54< celticminstrel> Right, that's a feature of the task.
20180114 00:33:07< celticminstrel> In order to verify that two strings are equal, you must match every character.
20180114 00:33:30< celticminstrel> If a single character doesn't match, you can bail out early, so that ends up being faster.
20180114 00:33:45< vultraz> but...?
20180114 00:34:05< celticminstrel> But if the strings are equal, you can't bail out early. You have to continue checking right until the last character.
20180114 00:34:07-!- stikonas_ [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20180114 00:34:21< vultraz> yes...?
20180114 00:34:34< celticminstrel> What part don't you understand here?
20180114 00:34:52< vultraz> with matches_name, you have a string like...
20180114 00:34:52< celticminstrel> The worst case performance for the algorithm of "comparing two strings" is the case when the strings are equal.
20180114 00:35:09< vultraz> "turn 1, turn 2, side 1 turn 2 end"
20180114 00:35:14< celticminstrel> That goes the same for matches_name, which is the same basic algorithm, just with a different underlying character comparator.
20180114 00:35:27< vultraz> and it checks whether a string, like "turn 2", is contained within between the ,'s
20180114 00:35:32< celticminstrel> (Or I assume it's the same.)
20180114 00:35:42< vultraz> my method splits that into a vector and compares each one
20180114 00:35:51< vultraz> and breaks on first match
20180114 00:35:57< celticminstrel> ...hold on, is it possible for variable substitution to introduce commas?
20180114 00:36:04< vultraz> I don't see where the extra performance hit comes in except perhaps the extra standardization step
20180114 00:36:20< vultraz> probably but you'd be a fool to do that
20180114 00:36:29< celticminstrel> Not necessarily.
20180114 00:36:50< vultraz> anyway
20180114 00:36:51< celticminstrel> Standardization means going through the entire string, so yeah, that's a slight performance hit in theory.
20180114 00:37:03< vultraz> well, it's modified in-place
20180114 00:37:09< celticminstrel> This is all in theory because these strings are really short, so the difference should be negligible.3
20180114 00:37:09< vultraz> and these strings are short
20180114 00:37:13< vultraz> just how much are we talking
20180114 00:37:20< vultraz> 0.5 ms?
20180114 00:37:21< celticminstrel> Sure it might be modified in-place, but it's still checking each character.
20180114 00:37:25< celticminstrel> 0.0001 ms?
20180114 00:37:43< vultraz> we're not NASA
20180114 00:37:54< vultraz> we don't need to worry about 1 ten-thousandth of a second
20180114 00:37:58< vultraz> :P
20180114 00:38:03< celticminstrel> That's why I said performance reasons aren't really sufficient to switch back to matches_name.
20180114 00:38:11< vultraz> OK
20180114 00:38:22< celticminstrel> There might however be other reasons to do so.
20180114 00:38:36< vultraz> go on
20180114 00:38:53< celticminstrel> I don't fully understand the system, but it does sound a bit like using matches_name is a bit simpler than using standardize_name.
20180114 00:40:01< vultraz> standardize_name just replaces spaces with _ and trims leading and trailing spaces
20180114 00:40:17< vultraz> matches_name did do some additional consideration of things like \n but I don't think we need to worry about that
20180114 00:40:52< celticminstrel> But with standardize_name you need to do it in two different places, depending on whether there are variables involved.
20180114 00:40:59< celticminstrel> I don't think that would be the case with matches_name?
20180114 00:54:13< celticminstrel> I don't know what you mean about \n, maybe that part's unnecessary.
20180114 00:59:55-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180114 01:00:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180114 01:55:11-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180114 01:55:21-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180114 03:12:23-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has quit [Quit: ZNC 1.6.5 - http://znc.in]
20180114 03:15:21-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has joined #wesnoth-dev
20180114 03:15:47-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has quit [Remote host closed the connection]
20180114 03:17:08-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has joined #wesnoth-dev
20180114 03:18:21-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has quit [Remote host closed the connection]
20180114 03:22:09-!- irker768 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20180114 03:23:13-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has joined #wesnoth-dev
20180114 03:23:48-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has quit [Remote host closed the connection]
20180114 03:24:14< TadCarlucci> vultraz, Consider $tad=1 firsttimeonly=no name=turn 1, turn $tad .. should it fire once or twice?
20180114 03:26:18-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has joined #wesnoth-dev
20180114 03:26:50-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has quit [Remote host closed the connection]
20180114 03:46:15-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180114 03:46:23-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180114 03:55:39-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has joined #wesnoth-dev
20180114 04:03:30< vultraz> TadCarlucci: once, of couse
20180114 04:04:07< vultraz> you can't do buffer overflow to introduce new keys by writing them into the values of other keys
20180114 04:13:32-!- senkwich [~senkwich@cpe-70-113-62-141.austin.res.rr.com] has quit [Remote host closed the connection]
20180114 04:14:25< TadCarlucci> @vultraz, I don't see "of course". "once per name" is just as logical.
20180114 04:14:43< vultraz> oh
20180114 04:14:44< vultraz> oh
20180114 04:14:47< vultraz> I misunderstood
20180114 04:15:06< vultraz> once.
20180114 04:15:15< vultraz> as soon as a match happens it fired
20180114 04:15:17< vultraz> fires
20180114 04:15:34< vultraz> you can't make an event fire multiple times by naming it twice
20180114 04:19:28< TadCarlucci> So if I need the block to run twice I need to waste space and duplicate it.
20180114 04:20:10< TadCarlucci> np. Just challenging to determine if it's implementation-defined or by-design.
20180114 04:20:10< vultraz> ...no?
20180114 04:20:17< vultraz> just use [repeat]
20180114 04:20:19< vultraz> jeez
20180114 04:22:11< vultraz> no need to duplicate
20180114 04:23:56< TadCarlucci> I'm wondering if that's not true by considering names and filters and if it's possible to design variable transitions which could not be [repeated] because the filters would be wrong.
20180114 04:27:57< TadCarlucci> vultraz, So it's "if event in name then if filter then block" instead of "for event in name do if filter then block"
20180114 04:42:31< vultraz> yes
20180114 06:25:57-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180114 06:26:05-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180114 06:31:16-!- wajeemba [~wajeemba@2601:449:202:25b8:34d0:35dd:f465:a589] has quit [Quit: Leaving]
20180114 06:38:53-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20180114 06:39:04-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20180114 07:02:27-!- celticminstrel is now known as celmin|sleep
20180114 07:06:40-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20180114 08:38:31-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20180114 08:42:58< zookeeper> vultraz, what's this event name standardization thing about? just engine stuff?
20180114 08:43:15< vultraz> Yes
20180114 08:43:40< zookeeper> great, then i don't need to know :p
20180114 09:14:04< vn971> hmm, I wonder, are wesnoth variables exposed as a metatable somewhere in Lua API? So that I could write
20180114 09:14:05< vn971> wesnoth.variables.abcd = "test"
20180114 09:14:05< vn971> print(wesnoth.variables.hello_neo)
20180114 09:15:28< vn971> // The API I know about is the straight-forward wesnoth.set_variable, wesnoth.get_variable. Judging by unit.variables, having a metatable is very convenient.
20180114 09:41:48< vn971> Oh. Implemented it, wanted to PR and found it's alreaby being added in /data/lua/core.lua   I need to document it on the wiki then. Wiki didn't say a thing about `wml.variable.proxy`.
20180114 09:52:14< vn971> I don't get it though. Here's my implementation: https://gist.github.com/vn971/545941f1f1ca9c68838bca20b1161871   Here is the relevant quote from core.lua https://gist.github.com/vn971/fb0cdb494eaa006101b4d537f0239cb7   WTF?
20180114 10:05:42< vn971> UPD: OK, it seems that the current code in core.lua also sets up proxy tables for sub-fields. Like changing a field of a table you got from wesnoth.variable.proxy would auto-update the relevant variable itself. Not sure. Couldn't make it work. But someone maybe can.
20180114 10:09:31< Ravana_> helper.set_wml_var_metatable {}
20180114 10:20:32< Ravana_> I believe wml.* is all without documentation still
20180114 10:51:20-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20180114 11:17:06-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20180114 11:28:50-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20180114 11:58:53< vn971> Ravana_: helper.set_wml_var_metatable  is written to have many undesired effects, which I would not want: https://wiki.wesnoth.org/LuaWML:Variables#helper.set_wml_var_metatable   As I understand it, set_wml_var_metatable is not an API in the common sense, but actually something that modifies your _G environment.
20180114 11:59:19< vn971> Anyways, I've created a simple PR: https://github.com/wesnoth/wesnoth/pull/2370  Would also document the API on the wiki if it gets merged.
20180114 12:02:57-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20180114 12:23:02< Ravana_> it is written to have side effects if you made _G hold wml variables
20180114 12:23:11< Ravana_> it is sensible to create different table for those
20180114 12:32:34< vn971> Ravana_: Not sure. It's hard for me to understand the conception. What I do understand is a code like  wesnoth.set_variable("smth", 1)  or  wesnoth.variables.smth = 1. On the other hand, I see no variable assignments here: https://wiki.wesnoth.org/LuaWML:Variables#helper.set_wml_var_metatable  Do they happen, like, automagically, whenever I create something that is a wml table? If that's the case, I would certainly like to avoid thi
20180114 12:32:35< vn971> s level of magic.
20180114 12:32:43< vn971> * the concept
20180114 12:34:16< vn971> In other words, if writing this `my_persistent_variable = 42` would change any wesnoth variable, I would like to avoid this helper at all costs.
20180114 12:36:18< Ravana_> my_persistent_variable is _G.my_persistent_variable
20180114 12:36:35< Ravana_> and you are warned not to assign variables to _G
20180114 12:36:39< Ravana_> I use it as
20180114 12:36:45< Ravana_> V = helper.set_wml_var_metatable {}
20180114 12:37:06< Ravana_> V.ORM_difficulty_setting = 1
20180114 12:37:13< Ravana_> local adr = V.ORM_difficulty_setting
20180114 12:46:39< vn971> Ravana_: ah, that seems to be an OK option. Thanks for explaining. I also see it uses the "proxy" thing under the hood. So it could probably allow changing sub-fields when you change them in the proxy. (Haven't tested, don't know for sure.)
20180114 12:47:27< Ravana_> checking its implementation it handles wml objects and arrays as well
20180114 12:48:16< vn971> That also means that my PR is kinda fishy, because it just introduces a yet another way to get/set variables. Simpler and faster than the "proxy", with no support for sub-fields, but still, yet another way to do a thing.
20180114 12:49:11< Ravana_> noticeable performance difference?
20180114 12:50:14< vn971> Ravana_: nope, probably not.:DD Could _maybe_ me measurable if anybody changes variables in a loop 1000 times, but otherwise, it's only simplicity.
20180114 12:52:34< vn971> Maybe I should refrain from using the word "fast", because it only sounds like premature optimisation. But what I really like is simplicity. So if I get something from wesnoth variable, I expect the variable not to change when I change the extracted data (which is exactly what proxy could do, if I get it right).
20180114 12:55:14-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has joined #wesnoth-dev
20180114 13:34:48-!- EliDupree2 [~quassel@2604:a880:400:d0::9bb:2001] has quit [Remote host closed the connection]
20180114 13:35:23-!- EliDupree [~quassel@2604:a880:400:d0::9bb:2001] has joined #wesnoth-dev
20180114 13:49:28-!- irker818 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20180114 13:49:28< irker818> wesnoth/wesnoth:master V N edc52423c4 Lua: add variables metatable AppVeyor: vs2013/Debug Failed
20180114 13:49:28< irker818> Details: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-1067
20180114 14:23:16< Soliton> JyrkiVesterinen: the "no_backslashes" branch can be removed, right?
20180114 14:24:10< JyrkiVesterinen> Oh, yes.
20180114 14:24:23< JyrkiVesterinen> I had forgotten that I had put it to the upstream repository.
20180114 14:25:00< Soliton> no worries. just trying to clean up our branches a bit.
20180114 14:26:47< Soliton> celmin|sleep: fix_2280 is also a branch that was merged that can be deleted, right?
20180114 14:29:48< Soliton> i guess any merged branches can be removed. there are a couple more from celmin|sleep and gfgtdf.
20180114 14:48:46-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20180114 15:03:16< celmin|sleep> Pretty sure it is, yeah.
20180114 15:05:18< celmin|sleep> vn971, Ravana_: I do have a WIP documentation for wml.* somewhere...
20180114 15:26:43< celmin|sleep> https://wiki.wesnoth.org/LuaAPI
20180114 15:27:10< celmin|sleep> It's not linked anywhere because I didn't think it was ready for general use.
20180114 15:27:28< celmin|sleep> Also, it looks like I didn't actually get around to documenting wml.* there.
20180114 15:28:06< celmin|sleep> Anyway, if anyone would like to document wml.*, that's the place to do it IMO.
20180114 15:28:35-!- celmin|sleep is now known as celticminstrel
20180114 15:34:07< celticminstrel> (Don't just go transferring wesnoth.* stuff there though.)
20180114 16:43:14-!- Oebele_ [~quassel@143.177.58.202] has joined #wesnoth-dev
20180114 16:50:02-!- irker818 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20180114 17:18:19-!- irker479 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20180114 17:18:19< irker479> wesnoth/wesnoth:master anatoly techtonik bda1d6f272  Use non-interactive mode until AppVeyor AppVeyor: 1/6 builds failed
20180114 17:18:19< irker479> Details vs2013/Release: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-1068
20180114 18:13:44< irker479> wesnoth/wesnoth:master V N edc52423c4 Lua: add variables metatable AppVeyor: 1/4 builds failed
20180114 18:13:45< irker479> Details vs2013/Debug: https://ci.appveyor.com/project/wesnoth/wesnoth/build/Wesnoth-VS2013-master-1067
20180114 18:16:23< celticminstrel> Again irker seems to be reporting things on master that are actually not merged...
20180114 18:27:24-!- vultraz [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20180114 18:28:16-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20180114 18:40:59< celticminstrel> Yeah vultraz, now is definitely not the time for major refactors.
20180114 18:41:17< vultraz> What?
20180114 18:41:20< vultraz> What did I say
20180114 18:41:40< celticminstrel> It's a bit late now, but basically you should've never touched the event iteration stuff at all.
20180114 18:42:31< celticminstrel> Because now we need to do all the extra work to ensure it still works properly before release.
20180114 19:02:11< vultraz> you're right
20180114 19:55:15< irker479> wesnoth/wesnoth:master V N 9e7321e366 Lua: add variables metatable AppVeyor: All builds passed
20180114 20:22:34-!- TheJJ [~rofl@ipbcc36896.dynamic.kabel-deutschland.de] has quit [Ping timeout: 252 seconds]
20180114 20:38:50-!- fabi_ [~fabi@2a02:810c:c840:2e65:e938:58c6:b825:8385] has joined #wesnoth-dev
20180114 20:39:22-!- fabi [~fabi@wesnoth/developer/fendrin] has quit [Ping timeout: 265 seconds]
20180114 21:37:12-!- vultraz [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20180114 22:11:45-!- JyrkiVesterinen [~JyrkiVest@85-23-197-3.bb.dnainternet.fi] has quit [Quit: .]
20180114 22:49:06-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Read error: Connection reset by peer]
20180114 22:49:11-!- celmin [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20180114 23:12:17-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20180114 23:42:35-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 256 seconds]
20180114 23:47:48-!- Oebele_ [~quassel@143.177.58.202] has quit [Remote host closed the connection]
--- Log closed Mon Jan 15 00:00:43 2018