--- Log opened Sun Oct 02 00:00:12 2016
--- Day changed Sun Oct 02 2016
20161002 00:00:12-!- tad_carlucci [~tadcarluc@173.217.65.103] has joined #wesnoth-dev
20161002 00:00:22-!- tad_ [add94167@gateway/web/freenode/ip.173.217.65.103] has quit [Quit: Page closed]
20161002 00:00:36-!- tad_carlucci [~tadcarluc@173.217.65.103] has left #wesnoth-dev []
20161002 00:02:57< irker916> wesnoth: Charles Dang wesnoth:master ffe7884f533b / src/ (5 files in 3 dirs): Fixed skip_ai_moves preference operating inversely to its chosen state https://github.com/wesnoth/wesnoth/commit/ffe7884f533bd9cce2ef053ec3f5b366fadd8745
20161002 00:03:05< vultraz> restarting computer
20161002 00:03:08< vultraz> since i think it's dying :|
20161002 00:03:36< vultraz> i discovered another bug
20161002 00:03:38< vultraz> btw
20161002 00:03:42-!- tad_ [~tadcarluc@173.217.65.103] has joined #wesnoth-dev
20161002 00:03:47< vultraz> toggling that setting mid-game has no effect
20161002 00:03:55< vultraz> tad_: committed the fix
20161002 00:03:58-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Remote host closed the connection]
20161002 00:04:45-!- tad_ [~tadcarluc@173.217.65.103] has quit [Client Quit]
20161002 00:05:07-!- tad_ [~tadcarluc@173.217.65.103] has joined #wesnoth-dev
20161002 00:05:26-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161002 00:05:42< vultraz_iOS> Time to see if my computer is dying
20161002 00:06:40< vultraz_iOS> Ok it's dying :|
20161002 00:10:12< vultraz_iOS> Wait maybe not
20161002 00:10:20-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161002 00:11:56-!- tad_ [~tadcarluc@173.217.65.103] has quit [Quit: Leaving]
20161002 00:12:26-!- tad_ [~tadcarluc@173.217.65.103] has joined #wesnoth-dev
20161002 00:12:32< irker916> wesnoth: mattsc wesnoth:ai-improvements-guardians 6d7680494de0 / src/ai/default/ (ca_move_to_targets.cpp ca_move_to_targets.hpp): Default AI MtT CA: do not evaluate movemaps until needed https://github.com/wesnoth/wesnoth/commit/6d7680494de0b9f24dc7614fedb53cf9d58e7473
20161002 00:12:34< irker916> wesnoth: mattsc wesnoth:ai-improvements-guardians eefc28c13873 / src/ai/default/ca_move_to_targets.cpp: Default AI MtT CA: remove guardian moves before moving other units https://github.com/wesnoth/wesnoth/commit/eefc28c1387309e881e06d0e2ea46c57031d7a5a
20161002 00:12:50< mattsc> For those of you interested, this ^ is in PR 807  https://github.com/wesnoth/wesnoth/pull/807
20161002 00:13:04 * celticminstrel will look later.
20161002 00:13:12 * mattsc is off right now anyway
20161002 00:14:07 * tad_ is playing with Hexchat because he's tired of using the web interface ...
20161002 00:14:27< mattsc> Btw, this was reported way back in 1.11.6 or so by Bob_the
20161002 00:14:33< mattsc> _Mighty
20161002 00:16:25< celticminstrel> ...wait, does this mean you updated the XCode project, mattsc?
20161002 00:20:56-!- tad_ [~tadcarluc@173.217.65.103] has quit [Quit: Leaving]
20161002 00:21:19-!- tad_ [~tadcarluc@173.217.65.103] has joined #wesnoth-dev
20161002 00:24:55-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: noy]
20161002 00:33:01-!- tad_ [~tadcarluc@173.217.65.103] has quit [Quit: Leaving]
20161002 00:35:11-!- tad_ [~tadcarluc@173.217.65.103] has joined #wesnoth-dev
20161002 00:35:14-!- ancestral [~ancestral@63.236.20.2] has joined #wesnoth-dev
20161002 00:45:37-!- Bonobo [~Bonobo@2001:44b8:254:3200:c08f:e86c:d1f:a404] has joined #wesnoth-dev
20161002 00:45:45-!- Appleman1234 [~Appleman1@KD119104052245.au-net.ne.jp] has joined #wesnoth-dev
20161002 00:46:42-!- ancestral [~ancestral@63.236.20.2] has quit [Ping timeout: 264 seconds]
20161002 01:07:15< tad_> Yeah! One part down. luaL_typerror ==> luaW_type_error and no changes to Lua needed. Now to see if I can get strcoll ==> strcmp in Lua when we build without changing the source code ...
20161002 01:13:57-!- travis-ci [~travis-ci@ec2-54-158-205-155.compute-1.amazonaws.com] has joined #wesnoth-dev
20161002 01:13:58< travis-ci> wesnoth/wesnoth#11258 (ai-improvements-guardians - eefc28c : mattsc): The build has errored.
20161002 01:13:58< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/164354010
20161002 01:13:58-!- travis-ci [~travis-ci@ec2-54-158-205-155.compute-1.amazonaws.com] has left #wesnoth-dev []
20161002 01:46:34-!- gfgtdf_ [~chatzilla@x4e368fc1.dyn.telefonica.de] has joined #wesnoth-dev
20161002 01:47:09-!- gfgtdf [~chatzilla@x4e36ae97.dyn.telefonica.de] has quit [Read error: Connection reset by peer]
20161002 01:47:14-!- gfgtdf_ is now known as gfgtdf
20161002 01:48:14< vultraz> tad_: I'm curious, why did 5.3 rename a whole bunch of functions
20161002 01:48:32< vultraz> i remember i had to find a pr from another project to find the right new names for a bunch of stuff
20161002 01:48:38-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161002 01:50:56< vultraz> celticminstrel: anything on the flg dialog not displaying in join?
20161002 01:57:53< mattsc> celticminstrel: I updated the Xcode project locally.
20161002 01:58:28< mattsc> I wasn’t going to commit this without talking to you first since it often screws up one of your WIPs when doing so; and I only got back last night.
20161002 02:06:47< tad_> vultraz, I don't know that 5.3 renamed any functions in the API. A few more deprecated. Which were you thinking of?
20161002 02:09:14< mattsc> Btw, this is where the guardians taking a long time was first reported (or at least the first time that I am aware of):
20161002 02:09:15< mattsc> https://forums.wesnoth.org/viewtopic.php?f=5&t=40745&p=575565#p575565
20161002 02:10:55< vultraz> hm. looking at my old pr I actually only see is lua_objlen -> lua_rawlen and luaL_checkint -> luaL_checkinteger
20161002 02:11:00< vultraz> thought there were more
20161002 02:11:59< tad_> Those were macros which have been deprecated .. note that we had to fix them with static_cast<int> and won't need to any longer. That happens to be what I'm working on right now.
20161002 02:12:37< vultraz> ah, cleanup!
20161002 02:12:37< celticminstrel> mattsc: I don't currently have any WIP, so go ahead.
20161002 02:15:06< tad_> With those macros gone I _might_ be able to eliminate the last edits in the Lua header .. that leaves strcoll/strcmp and the exception thunk and I think I can eliminate or refactor those. I'm actually back to being hopefull we can use a clean, unmodified Lua source kit. If so, I might rename them back to *.c and use a compiler flag on them .. we'll see.
20161002 02:16:06< vultraz> :o
20161002 02:16:26< vultraz> you mean, no more tiresome manual updates when we want to bump lua versions?
20161002 02:18:17< irker916> wesnoth: mattsc wesnoth:master 52a4f2a0d1d2 / projectfiles/Xcode/Wesnoth.xcodeproj/project.pbxproj: Update Xcode project https://github.com/wesnoth/wesnoth/commit/52a4f2a0d1d2bbef14e065c717e81666d5943e0e
20161002 02:18:31< mattsc> celticminstrel: ^
20161002 02:19:35-!- vultraz_iOS [uid24821@wesnoth/developer/vultraz] has quit [Quit: Connection closed for inactivity]
20161002 02:23:11< tad_> vultraz, That is my goal. Not positive I can attain it. But I am certainly reducing the amount of it so far.
20161002 02:24:35< tad_> vultraz, celticminstrel which raises the question: should we update to Lua 5.3.3 (current version) or should we switch to LuaJIT (which is at 5.2.4 and won't be up to 5.3 for a while yet)
20161002 02:25:08< celticminstrel> I have no idea.
20161002 02:25:18< irker916> wesnoth: Charles Dang wesnoth:master 1d1f426e6912 / src/gui/dialogs/lobby/ (lobby.cpp lobby.hpp): MP Lobby: some minor cleanup https://github.com/wesnoth/wesnoth/commit/1d1f426e69124d03010c423ae8d1ec5746d838b6
20161002 02:25:21< tad_> Assuming, of course, I can get us back to 'vanilla' Lua
20161002 02:26:54< tad_> LuaJIT is 2x to 100x faster than stock Lua. For most people it's a drop-in replacement if you don't need 5.3 (obviously we don't, now) but there is a __slight__ chance we can't use LuaJIT
20161002 02:27:29< vultraz> what is LuaJIT?
20161002 02:27:40< tad_> Lua Just-in-time
20161002 02:28:21< tad_> It compiles as it's executing with the idea being the compiler provides the next bytecode just as the interpreter is going to need it.
20161002 02:28:35< vultraz> ....what?
20161002 02:28:49< vultraz> I understood nothing you just said :P
20161002 02:29:17< tad_> Right now when we load a Lua script we stop everything and Lua compiles it to bytecode.
20161002 02:30:14< tad_> LuaJIT runs the compiler in parallel with the bytecode virtual machine with the goal of getting the next line of code to the interpreter just in time and not later. Early is OK.
20161002 02:32:05< tad_> I played with it on my Apache server and it was like .. ok Lua, cool .. how about LuaJIT? WOW! I needed a 5-point harnes and headrest on my chair because it was ZOOM! 
20161002 02:32:25-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 272 seconds]
20161002 02:36:39< vultraz> tad_: iiinnteresttiingg
20161002 02:36:45< vultraz> speed is good
20161002 02:37:20< celticminstrel> I'm not sure how much of an issue it really is in Wesnoth though.
20161002 02:37:55< celticminstrel> It would affect [lua] blocks in events, basically. AI scripts are precompiled on side turn 1, so it wouldn't speed those up at all.
20161002 02:38:14< celticminstrel> [lua] blocks outside of events are similarly compiled (and run) only once at startup.
20161002 02:38:29< celticminstrel> vultraz: So which is more important? Speed, or upgrading to Lua 5.3? :P
20161002 02:38:40< vultraz> :(
20161002 02:39:00< gfgtdf> what are the avantgaes of 5.3 ?
20161002 02:39:14< gfgtdf> advantages
20161002 02:39:32< tad_> You're probably right on the speed advantages. We're so slow loading a new scenario 1 second won't matter.
20161002 02:40:25< gfgtdf> uhm reven though the lua file is onyl excuted once thits function are still called often later
20161002 02:40:35< tad_> The advantages of 5.3? Cleaner implementation. Some cruft removed. Main improvements we'll see are Lua separated integers from floats and it's all 64-bit now.
20161002 02:41:34< gfgtdf> tad_: i think the floats are also 64 bit before and since lua 5.2 don't have ints i dont see the point in that.
20161002 02:42:08< tad_> That __might__ mean some UMC (I'm thinking RPG-type stuff mainly) __might__ notice some calculations give different results.
20161002 02:42:21< gfgtdf> tad_: and 'cleaner  implementation' soundly liek an implentation detail of the lua c++ code.
20161002 02:42:27< celticminstrel> gfgtdf: If you're referring to the AI scripts, then yes; but the fact that it's pre-compiled does mean that JIT won't really help.
20161002 02:42:33< gfgtdf> sounds like*
20161002 02:42:58< tad_> Garbage collection was improved for 5.3 .. might help with our memory footprint.
20161002 02:42:58< celticminstrel> tad_: How many of those cases would mean getting the expected result instead of an unexpected result? :P
20161002 02:43:14< gfgtdf> celticminstrel: how so?  JIT does sped up the execution of tose functions not the 'compilation' time.
20161002 02:43:42< celticminstrel> From what tad_ said, JIT speeds things up by compiling and executing at the same time, effectively.
20161002 02:44:01< celticminstrel> So if you pre-compile anyway, it won't make any difference.
20161002 02:44:06< celticminstrel> Unless I misunderstood what he said.
20161002 02:45:12< tad_> celticminstrel, There's probably a lot going on in JIT. I've never done a JIT compiler so I don't know the internals. It benchmarks faster, that I know. And I've seen it be faster. But it it matters to Wesnoth I dunno.
20161002 02:45:43< tad_> For Apache it made a huge difference. But Apache recompiles the Lua for each request  .. vastly different than here.
20161002 02:45:50< gfgtdf> celticminstrel: hmm usually JIT means that you lazily (on demand) compiles lua bytecode into cpu  bytecode instead of 'interpreting' lua bytecode.
20161002 02:46:33< tad_> As I say, I've never looked at the internals; just the blackbox comparisons.
20161002 02:47:21< tad_> It's a question which can be re-asked if we upgrade to 5.3 because JIT will go to 5.3 .. it's just not there today.
20161002 02:47:50< celticminstrel> Fair enough.
20161002 02:49:20< irker916> wesnoth: Charles Dang wesnoth:master 30d7df8094dc / data/gui/widget/panel_box_display.cfg: Fix blurring not being displayed for box_display panels (such as in the titlescr https://github.com/wesnoth/wesnoth/commit/30d7df8094dc6877bccbce0e83f4925305cc5d8d
20161002 02:50:23< tad_> As to integer vs float .. consider n=3.14 and let X = 2/n .. in 5.2 it is 2.0/n in 5.3 it is 2/floor(n) .. so change to 2.0/n and you're fine.
20161002 02:50:50< tad_> But if you did n/2 it won't matter because it's n/tofloat(2) in both versions.
20161002 02:51:38< tad_> Sorta like the issue in C/C++ when auto-coersing
20161002 02:52:48< gfgtdf> tad_: so when one operant is an integer it perfoms an integer devisions? that sounds unexpected and liek its breaking many pgrograms.
20161002 02:52:54< gfgtdf> tad_: where did you read that ?
20161002 02:53:06< tad_> That's how I read it.
20161002 02:53:13< tad_> I can be wrong, of course.
20161002 02:53:40< tad_> https://www.lua.org/manual/5.3/manual.html#8
20161002 02:55:24< tad_> I don't expect most of our Lua scripts would even be effected by that. Maybe some in the AI. Maybe some UMC.
20161002 02:56:17< gfgtdf> tad_: hmm well it saiy that changes in arethmetics shodul onyl effect codes that rely on some kind of overflow, which i'd say isnt that case for te example above.
20161002 02:56:26< tad_> The big thing about 5.3 for us, as programmers, is those deprecated 'functions' (actually macros) don't cast any more so we won't get those warnings
20161002 02:56:43< gfgtdf> tad_: also it seems to adda a new integer devision operator // explictly for integer devisions, t
20161002 02:57:22< tad_> yes, but that's something we won't be using right away .. it's nice, but new
20161002 02:57:25< gfgtdf> tad_: an integer devision operator // woudl actually be quite nice, since its something i have missed when writing my own addons
20161002 02:59:05< gfgtdf> or rather in my lua code contributed to mainline https://github.com/wesnoth/wesnoth/blob/master/data/lua/cave_map_generator.lua#L14
20161002 02:59:17< celticminstrel> I personally thing the integer division operator is silly.
20161002 02:59:21< celticminstrel> Python has it too.
20161002 02:59:25< celticminstrel> ^think
20161002 02:59:41< celticminstrel> I mean, what's wrong with trunc(n/2) instead of n//2?
20161002 02:59:57< celticminstrel> (Where trunc() means "round towards 0".)
20161002 03:00:08< tad_> celticminstrel, because truncating a float is imprecise.
20161002 03:00:09< celticminstrel> To me, that makes more sense.
20161002 03:02:18< tad_> Coming from back when the choice was COBOL, FORTRAN or 360 Assembly .. I like having the option of using integer divide and integer remainder instead of having to use floats.
20161002 03:03:03< tad_> But, back then you could actually SEE the difference in a float divide vs an integer divide :P
20161002 03:03:42< gfgtdf> tad_: i wonder how you'll handle our exception halding code when porting to luajit ?
20161002 03:04:09< gfgtdf> handling*
20161002 03:04:50< tad_> gfgtdf, I'm thinking about that. I've only glanced at it but I'm wondering if it needs to be **in** the Lua code or if it can become a try/catch around the Lua *call functions.
20161002 03:06:32< gfgtdf> tad_: well the purpose of this code is exactly to make try/catch around lua *call functions work, so my guess would be no.
20161002 03:06:57< tad_> I'll have to set up some tests which C++ calls into Lua, Lua calls to a throw in C++ and see how it's handled. The issue is we want to be sure the Lua stack unwinds in a sane manner. I __think__ I can do that by installing a Lua panic function .. we'll see.
20161002 03:10:33< tad_> We can't be the only people who call Lua, have Lua call C++ and need to deal with exceptions. So I'm thinking it's either an artifact from an old Lua which didn't do it, or did it wrong, or I'll find some guidance on how to do it without having to hand-hack Lua like we do.
20161002 03:12:27< gfgtdf> tad_: we sureley arent, here is someone else who has this problem: http://lua-users.org/lists/lua-l/2015-03/msg00201.html
20161002 03:13:37< gfgtdf> tad_: have to go
20161002 03:13:38-!- gfgtdf [~chatzilla@x4e368fc1.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]
20161002 03:22:26-!- stikonas [~gentoo@wesnoth/translator/stikonas] has quit [Quit: Konversation terminated!]
20161002 03:34:22-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161002 03:37:45-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 248 seconds]
20161002 03:37:45-!- wedge010 is now known as wedge009
20161002 03:52:07< tad_> celticminstrel, you up for a code-read in "C"? See if you're seeing what I'm seeing?
20161002 03:55:28< celticminstrel> ???
20161002 03:56:46< tad_> commit 299a29f99a84767731dbadd540712d1a37e5e10d
20161002 03:56:50-!- hk238 [~kvirc@unaffiliated/hk238] has joined #wesnoth-dev
20161002 03:57:25< tad_> I believe it's wrong and should be reverted. Actually that should be "should never, again, be hand-applied" ...
20161002 03:58:51< tad_> It purports to correct an overrun/off-by-one but it appears to me it actually causes one, instead.
20161002 04:00:07< celticminstrel> Uhhh...
20161002 04:00:12< tad_> If token == 256 then, with that commit, line 81 reads: onst char *s = luaX_tokens[-1];
20161002 04:00:23< tad_> And is excuted
20161002 04:00:49< celticminstrel> Why 256?
20161002 04:01:49< tad_> because what it's trying to do is printf("%c") if the token is an unsigned char [0 .. 255] but Lua uses 1 .. 256
20161002 04:02:17< tad_> sorry. no.
20161002 04:04:13< tad_> see, I do need to talk it out. There is an off-by-one there .. but I think this is the wrong fix, if it's needed. I think I'm gonna have to whack Lua a bit ...
20161002 04:05:17< celticminstrel> I don't really know what's happening in that commit, sorry.
20161002 04:05:32< celticminstrel> Like, what FIRST_RESERVED is for instance.
20161002 04:05:34< tad_> Go to the source.
20161002 04:06:32< tad_> Actually, I'm trying to work it out and I think there is an off-by-one there but the commit is not the fix. 
20161002 04:07:07< tad_> It converts an off-by-one into a buffer overrun ...
20161002 04:11:18< tad_> Let token=256 .. that is not less than FIRST_RESERVED-1 (257-1) so goto else ... 256-257 is -1 so index the table by -1 which does not exist .. 256 is less than TK_EOS (260something) so return the garbage from the bad index into the table as a const char* (s)
20161002 04:12:25< tad_> If we use the original code token=256 becomes token=0 .. but token=256 can't occur because it would need to require const char 'c' == 256 which is not possible.
20161002 04:13:05< tad_> Therefore the commit is junk. But I should file the error with roberto @ lua.org 
20161002 04:26:33< tad_> Yes. It's not a bug and I should "revert" the commit. I will work up an email to roberto so he can decide how to document the fact there is NO token==256 so nobody else makes this mistake and leaves it in their code for 3 years before someone checks their work.
20161002 04:28:57< vultraz> smart tad is smart
20161002 04:30:38< tad_> Compilers I understand. JIT I no grok but lexers are easy. I can see WHY roberto did it this way, but it needs to be documented so nobody misunderstands WHY.
20161002 04:40:41-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has quit [Remote host closed the connection]
20161002 04:40:47-!- janebot [~Gambot@unaffiliated/gambit/bot/gambot] has joined #wesnoth-dev
20161002 04:45:05-!- Kwandulin [~Miranda@p200300760F2C71AADCC3CA269F3FDED8.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161002 04:45:28-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161002 04:49:11-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 264 seconds]
20161002 04:49:11-!- wedge010 is now known as wedge009
20161002 04:55:12-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Read error: Connection reset by peer]
20161002 04:55:33-!- Kwandulin [~Miranda@p200300760F2C71AADCC3CA269F3FDED8.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
20161002 04:55:55-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161002 05:10:12-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20161002 05:13:14< tad_> vultraz, Need an opinion on an ancient change to Lua involving 'double' and the value of PI.
20161002 05:15:34-!- JyrkiVesterinen [~JyrkiVest@87-100-201-129.bb.dnainternet.fi] has joined #wesnoth-dev
20161002 05:25:37< tad_> vultraz, nevermind. If it makes a difference then it's a bug in Boost or your compiler .. I'm "reverting" the old commit by not hand applying it.
20161002 05:26:15< vultraz> I likely couldn't give you a good answer anyway :P
20161002 05:28:15< tad_> Actually, it's just an opinion. Boost declares 'pi' using two constants. One for 128-bit floats and another for 256-bit floats. We use 'double' as does Lua and that's a 64-bit float.
20161002 05:28:51< tad_> So the hand patch was to use Boost's 'pi' instead of Lua's but Lua uses the most-precise value possible for 64-bit floats
20161002 05:29:36< tad_> So if using boost gives a different value either they have a typo or your compiler didn't do the conversion correctly. 
20161002 05:30:54< tad_> I know I'm being anal about these hand applied changes but they're a pain and, except for c++ exceptions, I am __still_ 'vanilla' Lua source ...
20161002 05:33:29-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has quit [Quit: And lo! The computer falls into a deep sleep, to awake again some other day!]
20161002 05:37:55-!- Kwandulin [~Miranda@p200300760F2C71AA40F9703B501884C7.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161002 05:40:54-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161002 05:46:18< JyrkiVesterinen> About LuaJIT:
20161002 05:46:20< JyrkiVesterinen> 20161002 02:37:55< celticminstrel> It would affect [lua] blocks in events, basically. AI scripts are precompiled on side turn 1, so it wouldn't speed those up at all.
20161002 05:46:48< JyrkiVesterinen> That is incorrect. The default Lua VM compiles Lua source code to Lua bytecode and then runs it in a bytecode interpreter.
20161002 05:47:07< JyrkiVesterinen> LuaJIT compiles Lua code to machine code that can be run much faster.
20161002 05:47:26< JyrkiVesterinen> LuaJIT would speed up everything-
20161002 05:47:32< JyrkiVesterinen> s/-/.
20161002 05:49:40-!- irker916 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161002 05:52:35< tad_> JyrkiVesterinen, That was pointed out. I think the final consensus was to continue upgrading to 5.3.3 from 5.2.3 and reconsider the idea when LuaJIT catches up.
20161002 05:53:17< JyrkiVesterinen> I decided to clarify it anyway because that point seemed to be quite unclearly said in the logs.
20161002 05:53:45< tad_> Yes. It was there, but you did state it more clearly.
20161002 05:54:46< JyrkiVesterinen> 20161002 03:10:33< tad_> We can't be the only people who call Lua, have Lua call C++ and need to deal with exceptions. So I'm thinking it's either an artifact from an old Lua which didn't do it, or did it wrong, or I'll find some guidance on how to do it without having to hand-hack Lua like we do.
20161002 05:55:02< JyrkiVesterinen> Regarding that, yes, we are not. My former employer had the same problem, too.
20161002 05:55:39< JyrkiVesterinen> Our way to handle it was to compile Lua as C++, which allows it to handle exceptions thrown by inner C++ gracefully.
20161002 05:56:07< tad_> I was reading on that. Roberto (prof who leads Lua team) answered it but I think he gave too-precise an answer. We already compile to C++, btw
20161002 05:56:23< tad_> So the issue is checking that Lua is in a sane state.
20161002 05:56:26< JyrkiVesterinen> If such an exception was thrown, lua_pcall() will return an error code (was it LUA_ERRERR? I can't recall.)
20161002 05:57:30< tad_> Roberto's answer was including thinkgs like Lua's calling malloc() and what to do it THAT throws.  Well, who cares? All I care about is that C++ exceptions pass through and Lua is still stable and not leaking memory.
20161002 05:57:59< JyrkiVesterinen> Our engine detected that situation. IIRC, we stored the exception somewhere in the Lua-to-C++ call layer before rethrowing it to Lua, and when lua_pcall() returned that error code, the C++-to-Lua layer fetched the exception from there and rethrew it.
20161002 05:58:09< tad_> So I've been thinking about the hand changes we use and how to test if we really even need them.
20161002 05:58:45< tad_> EXACTLY what I was thinking I'd do. Avoids all that editing of Lua source and gets the job done.
20161002 05:59:41< tad_> "Install a panic function" is how I phrase it. Catch the error, cause Lua to panic, catch the panic and rethrow.
20161002 06:00:04< JyrkiVesterinen> Sounds good. That method is used in production in highly popular mobile games and works well there.
20161002 06:00:48< tad_> and is a LOT easier to maintain than all this hand merging old commits and dealing with hand merge errors and visually spotted merge conflicts.
20161002 06:11:02< tad_> JyrkiVesterinen, If you're interested in what I've already committed in preparing for an upgrade to Lua 5.3.3 check my GL_Lua branch.
20161002 06:11:42< tad_> Still working on it. What I'm trying to do is document via commit what I'm tossing out.
20161002 06:16:34-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20161002 06:16:48< mordante> servus
20161002 06:20:23< JyrkiVesterinen> tad_: Your changes so far look good to me.
20161002 06:20:30< JyrkiVesterinen> I left one suggestion in GitHub.
20161002 06:21:35< tad_> ok. but remember the intention is to revert the current Lua 5.2.3 (modified) to match 5.2.3 (released) .. looking now
20161002 06:23:06< vultraz> tad_: so you're doing this in 2 stages... revert our code to match released, and then update?
20161002 06:24:04< tad_> As much as I can. My intention is to document what I'm changing in preparation for the upgrade. Refactor, revert, etc. So it's in the git history and doesn't just disappear
20161002 06:25:33< tad_> JyrkiVesterinen, IF you're referring to the refactor to luaW_type_error .. I think that's up to the calling site. If you're referring to the Lua internals .. I think that is the reason they deprecated the function .. we're abusing it (and so were others) .. IIRC Lua internally checks the metatable
20161002 06:27:06< tad_> vultraz, If I reach my goal I end up with two commits at the end. First deleteing all the Lua files, second adding the unchanged/released files and fixing the builds to force c++ instead of renaming.
20161002 06:27:29< JyrkiVesterinen> Hmm, Lua may well already check the metatable. I don't have experience about that because the games I developed earlier didn't use the __metatable field at all if I recall correctly.
20161002 06:27:33< vultraz> I approve of this
20161002 06:27:57< tad_> vultraz, It's probably all for 1.13.6+dev ...
20161002 06:28:05< vultraz> sure
20161002 06:29:06< tad_> JyrkiVesterinen, I have quibbles for some of the Lua source code but it's mainly programming style, not error. I might change my mind when I build 5.3.3 with -Wall .. we'll see.
20161002 06:29:34< vultraz> mordante: anything on the credits bug?
20161002 06:30:06< JyrkiVesterinen> As Lua is often compiled as an embedded library, its developers should ensure that it compiles with -Wall.
20161002 06:30:26< JyrkiVesterinen> Of course, it isn't certain, and new warnings get added when compilers progress.
20161002 06:31:30< JyrkiVesterinen> If Lua 5.3.3 won't compile with -Wall, then it would probably be best to store a "custom Lua fixes" patch somewhere in the repository.
20161002 06:32:00< JyrkiVesterinen> So that we could attempt to make future Lua updates by removing Lua, putting the new version in, applying the patch and fixing merge conflicts.
20161002 06:33:10-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161002 06:33:30-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161002 06:36:42< tad_> JyrkiVesterinen, lua.org seems to be mainly concerned with "C" and "C++" was an after-throught. So I'm waiting-and-seeing. I expect no messages for -Wall if I use "C" but we'll see about "C++" there might be some static_cast warnings there .. if so I will fix them and submit a patch to the mailing list.
20161002 06:37:36< tad_> JyrkiVesterinen, I already need to write one about that off-by-one I reverted asking them to document the 'hole' at token=256 so nobody else makes the same mistake.
20161002 06:39:26< JyrkiVesterinen> I meant a patch about fixes we're going to apply locally. (Unless you're saying that the Wesnoth variant of Lua would contain a comment that documents the hole.)
20161002 06:40:49< tad_> JyrkiVesterinen, sorry, thought that was vultraz and was about to reply to him about it .. yes .. a HOWTO document with a context-diff so future upgrades can be easier. This having to search for changes is a pain.
20161002 06:41:26< tad_> Although, since I'm being anal about the changes, I am finding many of them really should never have been made :)
20161002 06:42:03< JyrkiVesterinen> It's surprising that you can mix us up. Our writing styles are completely different. :/
20161002 06:42:29-!- Kwandulin_2 [~Miranda@p200300760F2C71AA40F9703B501884C7.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161002 06:42:32< tad_> It's 0200 here and I've been up since 0630 yesterday. :P
20161002 06:42:55< JyrkiVesterinen> Oh. Consider getting some sleep.
20161002 06:43:46< tad_> My sleep consideration unit (aka wife) is online playing her game so I'm getting a consideration-reprieve tonight.
20161002 06:43:51-!- Kwandulin [~Miranda@p200300760F2C71AA40F9703B501884C7.dip0.t-ipconnect.de] has quit [Ping timeout: 272 seconds]
20161002 06:43:58< shadowm> Why are you mentioning C and C++ in quotes?
20161002 06:44:32< JyrkiVesterinen> I very rarely stay up late - even less often if what I'm doing is helping an open source project. For me, my own well-being is much more important than the state of Wesnoth.
20161002 06:44:34< tad_> Personal habit. Offsettign them from a typo c
20161002 06:46:28< tad_> JyrkiVesterinen, Left to my own I'd get up around 1100 and work until the sun rises. Which was the shift I usually worked when I got paid for this. I'm retired now so it's all "government work" (that is, you'll never get paid for it, just like a gov't contract).
20161002 06:47:49< JyrkiVesterinen> For me, I have noticed that I often suffer from strong headache if I stay up late. I usually go to bed at around 23:30.
20161002 06:47:58< JyrkiVesterinen> (Europe uses 24-hour clock.)
20161002 06:48:00< tad_> vultraz, I could say: I've been doing this a long time. You see C and C++ and Java and Javascript .. all I see are flavors of Algol
20161002 06:48:21-!- enchi [enchilado@defocus/yummy/enchilado] has joined #wesnoth-dev
20161002 06:49:26< tad_> JyrkiVesterinen, I have my clock set to UTC on the desktop but "up late" is a local-time issue so I looked at the clock .. just don't tell my wife to do that :D
20161002 06:50:24< tad_> Her game uses PDT so she thinks it's only midnight ...
20161002 06:50:38< JyrkiVesterinen> :D
20161002 06:55:37-!- Kwandulin_2 [~Miranda@p200300760F2C71AA40F9703B501884C7.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds]
20161002 06:56:41< vultraz> tad_: the hell is Algol
20161002 06:58:14< tad_> Algol was the algorithmic language back when there was COBOL, FORTRAN, and Assembly. We're talking WAY back. 60s 70s timeframe .. when I learned to program.
20161002 06:58:50< tad_> It was the language which game us "do while" "repeat until" and "for" loops.
20161002 06:59:14-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has joined #wesnoth-dev
20161002 07:00:30< vultraz> geez
20161002 07:01:08< tad_> vultraz, OF course, for a blast from the past, the first REAL program I wrote was in "RPG" Report Program Generator. A real strange language.
20161002 07:04:12-!- Kwandulin [~Miranda@p200300760F2C716F40F9703B501884C7.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161002 07:30:49-!- bumbadadabum [~bumbadada@wesnoth/developer/bumbadadabum] has quit [Ping timeout: 248 seconds]
20161002 07:39:44< tad_> OK. Time to work out the inconsistency with strcoll vs strcmp in Lua. On the C++ side, we have non-translated strings which which we can sort and "should" be using strcmp for that.
20161002 07:40:04< tad_> And we have translated strings (t_string) which cannot be sorted just compared equal.
20161002 07:40:21< tad_> Except in one place .. the help viewer uses strcoll to sort them.
20161002 07:40:26< tad_> So far, so good.
20161002 07:40:34< tad_> But Lua .. it's a problem.
20161002 07:40:56< tad_> Lua uses strcoll by default. And we change it to use strcmp.
20161002 07:41:31< tad_> By using strcmp if Lua compares t_string < or <= we're doing it wrong for the locale
20161002 07:41:40< tad_> So Lua was originally correct.
20161002 07:42:23< tad_> But if we're comparing const char* ("C" locale) strings, strcoll will do it wrong because it will use the current locale.
20161002 07:42:46< tad_> So .. it's do it right for some strings and wrong for others no matter what we do.
20161002 07:43:37< tad_> But Lua as a setlocale function and we could use strcoll and simply tell the Lua users that they need to setlocale to "C" before comparing
20161002 07:44:27< tad_> But then if they know it will be a t_string, they'll need to ask (is this possible or must it be added) for the locale since they won't know it .. or they'll have to do the set/save/restore thing.
20161002 07:44:51< tad_> Gods I forgot what a pain locale was. :P
20161002 07:46:42< tad_> I'm tempted to revert back to strcoll and checking mainline and core Lua for string compares (GAK!) and add the set/save/restore thing and accept that we'll need to assist the UMC people with fixes should any be needed.
20161002 07:50:15-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161002 07:50:34-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161002 07:50:44-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20161002 07:59:31-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161002 08:07:12-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Quit: wedge009]
20161002 08:09:09-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161002 08:11:08-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Client Quit]
20161002 08:14:34-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161002 08:24:39< tad_> ARG! Of course. Lua has the ability to setlocale in the script. But we remove that function so our Lua scripts cannot call it! So we cannot fix the problem with strcmp vs strcoll so easily.
20161002 08:32:56-!- Kwandulin [~Miranda@p200300760F2C716F40F9703B501884C7.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161002 08:33:03-!- tad_ [~tadcarluc@173.217.65.103] has quit [Quit: Leaving]
20161002 08:37:23-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20161002 08:58:19-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Remote host closed the connection]
20161002 09:05:14-!- Kwandulin [~Miranda@p200300760F2C716F792AB8AF4F262A02.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161002 09:10:46-!- noy [~Noy@wesnoth/developer/noy] has quit [Quit: GO, GET TO THE CHOPPAH!!!]
20161002 09:31:34-!- travis-ci [~travis-ci@ec2-54-146-144-156.compute-1.amazonaws.com] has joined #wesnoth-dev
20161002 09:31:35< travis-ci> wesnoth/wesnoth#11258 (ai-improvements-guardians - eefc28c : mattsc): The build passed.
20161002 09:31:35< travis-ci> Build details : https://travis-ci.org/wesnoth/wesnoth/builds/164354010
20161002 09:31:35-!- travis-ci [~travis-ci@ec2-54-146-144-156.compute-1.amazonaws.com] has left #wesnoth-dev []
20161002 09:43:13-!- JyrkiVesterinen [~JyrkiVest@87-100-201-129.bb.dnainternet.fi] has quit [Quit: .]
20161002 10:40:10-!- Nikitaw99 [2e005032@gateway/web/freenode/ip.46.0.80.50] has joined #wesnoth-dev
20161002 10:40:18< Nikitaw99> hii
20161002 10:46:09-!- gfgtdf [~chatzilla@x4e368fc1.dyn.telefonica.de] has joined #wesnoth-dev
20161002 10:57:12< Nikitaw99> ?
20161002 10:57:19< loonycyborg> hi
20161002 10:57:23< Nikitaw99> ohai
20161002 10:57:31< Nikitaw99> this place is just too damn silent
20161002 10:57:54< loonycyborg> Generally people only talk when they have something to say :P
20161002 10:58:25< Nikitaw99> oh well
20161002 10:59:07< loonycyborg> But I still see a rather large volume of technical discussions in logs
20161002 10:59:31< loonycyborg> so it's not like this place is deader than disco
20161002 10:59:51< Nikitaw99> i am in progress of creating a campaign
20161002 10:59:59< Nikitaw99> got the first chapter partially done
20161002 11:01:39< Nikitaw99> http://forums.wesnoth.org/viewtopic.php?f=8&t=44675
20161002 11:04:59-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has joined #wesnoth-dev
20161002 11:06:06< loonycyborg> That's nice, but it doesn't seem that it's at level of completion that could result in much discussion :P
20161002 11:09:43-!- RatArmy [~RatArmy@om126237112064.9.openmobile.ne.jp] has joined #wesnoth-dev
20161002 11:11:32-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has joined #wesnoth-dev
20161002 11:38:29< Nikitaw99> loonycyborg: yeah
20161002 11:38:43< Nikitaw99> i need some ideas and maybe help with balancing
20161002 11:39:37< Nikitaw99> i mean, i am not sure what to put into the next chapter
20161002 11:41:50< Nikitaw99> since the port is destroyed, Jackquel and CO. are not able to set sail
20161002 11:43:39< Nikitaw99> hm....
20161002 11:43:55< Nikitaw99> can anybody give me a tutorial on how to make a world map for my campaign?
20161002 11:45:25-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20161002 11:45:50-!- stikonas [~gentoo@wesnoth/translator/stikonas] has joined #wesnoth-dev
20161002 11:52:57< zookeeper> Nikitaw99, there is no tutorial and it's very complicated anyway
20161002 11:53:34< zookeeper> you probably want to just use whichever existing map works best for your campaign
20161002 11:55:01-!- Kwandulin [~Miranda@p200300760F2C716F792AB8AF4F262A02.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161002 11:55:17< Nikitaw99> i want it to be pretty simple
20161002 11:55:37< Nikitaw99> i will be useful in story blocks
20161002 11:57:10-!- Nikitaw99 [2e005032@gateway/web/freenode/ip.46.0.80.50] has quit [Quit: Page closed]
20161002 11:57:21-!- allaroundArtist [~manahovma@46.0.80.50] has joined #wesnoth-dev
20161002 11:57:32-!- allaroundArtist is now known as Nikitaw99
20161002 11:57:58< Nikitaw99> sorry, just switched to my irc client
20161002 11:59:19< Nikitaw99> how do I change the font in mIRC?
20161002 12:00:02< zookeeper> view->font, i'd imagine
20161002 12:00:19< Nikitaw99> thanks
20161002 12:00:22< Nikitaw99> gonna pick a font
20161002 12:03:38-!- RatArmy [~RatArmy@om126237112064.9.openmobile.ne.jp] has quit [Quit: Leaving]
20161002 12:04:59< Nikitaw99> hm
20161002 12:05:11< Nikitaw99> ok, i am trying to make mIRC look like freenode
20161002 12:07:11< Nikitaw99> a bit done
20161002 12:07:21< Nikitaw99> anyway
20161002 12:07:31< Nikitaw99> i wanna make a simple map for my wesnoth campaign
20161002 12:07:38< Nikitaw99> world map to be precise
20161002 12:09:32< Nikitaw99> anyone could help with atleast something?
20161002 12:19:54< Nikitaw99> well, i guess i found a great base https://images.duckduckgo.com/iu/?u=http%3A%2F%2Fthumbs.dreamstime.com%2Ft%2Fold-blank-parchment-treasure-map-isolated-pirates-white-clipping-path-included-50074675.jpg&f=1
20161002 12:22:22< zookeeper> there's plenty of general-purpose fantasy cartography tutorials and whatnot on the internet
20161002 12:22:46< Nikitaw99> ok
20161002 12:24:41< Nikitaw99> i need a base background though
20161002 12:25:21-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161002 12:25:36-!- trewe [~trewe@2001:8a0:d111:bd01:936f:a116:597:ebda] has joined #wesnoth-dev
20161002 12:29:35< Nikitaw99> http://cdn.androidcentral.com/sites/androidcentral.com/files/imagecache/w550h500/wallpapers/blank-parchment-aps.jpg oooooooo
20161002 12:29:52-!- louis94 [~~louis94@91.178.241.115] has joined #wesnoth-dev
20161002 12:40:26-!- louis94 [~~louis94@91.178.241.115] has quit [Ping timeout: 252 seconds]
20161002 12:57:20< Nikitaw99> high quality r.i.p.
20161002 13:00:16< Nikitaw99> mmm
20161002 13:00:18< Nikitaw99> soo
20161002 13:00:40< Nikitaw99> i see that in the campaigns before battle we can see some marker thingies
20161002 13:00:48< Nikitaw99> like where the battle will go
20161002 13:01:03< Nikitaw99> and maybe what path the heroes went
20161002 13:01:12< Nikitaw99> how do i do them in my campaign?
20161002 13:01:22< Nikitaw99> (i'll use the wesnoth map as a placeholder)
20161002 13:04:09-!- wedge010 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
20161002 13:05:30-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20161002 13:05:31-!- wedge010 is now known as wedge009
20161002 13:07:45< zookeeper> Nikitaw99, which part of it is unclear?
20161002 13:11:59< Nikitaw99> zookeeper: i dont know how to do those markers at all
20161002 13:12:56-!- Nikitaw99 is now known as Nikitaw99_
20161002 13:14:11< zookeeper> well then you have to look at how they're done, and ask more specific questions if/when you don't understand some particular aspect of it
20161002 13:14:47-!- Nikitaw99 [2e005032@gateway/web/freenode/ip.46.0.80.50] has joined #wesnoth-dev
20161002 13:15:07< Nikitaw99_> zookeeper: ok, i'll check them out and stuf
20161002 13:15:10< Nikitaw99_> stuff*
20161002 13:15:15-!- Nikitaw99_ [~manahovma@46.0.80.50] has quit []
20161002 13:15:53< Nikitaw99> ok bam back to freenode irc client
20161002 13:17:47-!- celticminstrel [~celmin@unaffiliated/celticminstrel] has joined #wesnoth-dev
20161002 13:28:23-!- gfgtdf [~chatzilla@x4e368fc1.dyn.telefonica.de] has quit [Quit: ChatZilla 0.9.92 [Firefox 49.0.1/20160922113459]]
20161002 13:44:08-!- Nikitaw99 [2e005032@gateway/web/freenode/ip.46.0.80.50] has quit [Quit: Page closed]
20161002 13:49:32-!- Bonobo [~Bonobo@2001:44b8:254:3200:c08f:e86c:d1f:a404] has quit [Quit: Leaving]
20161002 13:59:09-!- Kwandulin [~Miranda@p200300760F2C716F9C94B593184288B3.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161002 13:59:51-!- DeFender1031 [~DeFender1@89-138-252-80.bb.netvision.net.il] has quit [Quit: I'm not back now.]
20161002 14:14:43< mordante> vultraz not really, still have some compilation issues
20161002 14:15:59< mattsc> celticminstrel: Good morning.  With the next release now planned for mid October, do you have time to add the new ai.get_attacks() for me to use with the high-XP CA before then?
20161002 14:19:07-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has joined #wesnoth-dev
20161002 14:21:16< vultraz> mordante: compilation issues?
20161002 14:25:55< celticminstrel> Oh right.
20161002 14:26:07< celticminstrel> What was it, again?
20161002 14:26:21< celticminstrel> Also I forgot to answer vultraz last night - I haven't looked at flg yet.
20161002 14:26:31< vultraz> ok
20161002 14:27:22< mattsc> celticminstrel: have the function return the list of own and enemy units covered by the filters, rather than the attack evaluations.
20161002 14:33:03< mattsc> celticminstrel: As a side note, I am currently working on having the MAIs properly ignore invisible units. I’m not sure if I’ll still get that into 1.13.6 though.
20161002 14:33:39< mattsc> I’ll also think about for which of them we might want to take [avoid] and [attacks] aspects into account.
20161002 14:45:46-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has quit [Quit: Connection closed for inactivity]
20161002 14:46:22< mattsc> Ooo, just noticed that I can hang Wesnoth by having the high-XP-attack CA try to attack a petrified unit.   :x 
20161002 14:46:52< mattsc> Not that petrified enemies one XP from leveling are likely to be encountered very often, but still …
20161002 15:07:04-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161002 15:14:05-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161002 15:21:38-!- Duthlet [~Duthlet@dslb-188-104-253-155.188.104.pools.vodafone-ip.de] has quit [Quit: leaving]
20161002 15:32:14-!- boucman_work [~boucman@gre92-5-82-237-199-7.fbx.proxad.net] has joined #wesnoth-dev
20161002 15:41:22-!- boucman_work [~boucman@gre92-5-82-237-199-7.fbx.proxad.net] has quit [Ping timeout: 265 seconds]
20161002 15:51:59< celticminstrel> vultraz: https://github.com/wesnoth/wesnoth/commit/ffe7884f533bd9cce2ef053ec3f5b366fadd8745#diff-fe92c47b8e93facd418f96f042f081e9R477
20161002 15:52:08< celticminstrel> Is it correct that there's no ! there?
20161002 15:52:24< celticminstrel> Also at https://github.com/wesnoth/wesnoth/commit/ffe7884f533bd9cce2ef053ec3f5b366fadd8745#diff-fe92c47b8e93facd418f96f042f081e9R477
20161002 15:52:47< celticminstrel> Wait, I was about to say the default should be false, but on second thoughts...
20161002 15:53:05-!- Kwandulin [~Miranda@p200300760F2C716F9C94B593184288B3.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161002 15:53:10< celticminstrel> Oh, no, I was right. The default should be false.
20161002 15:53:52< vultraz> both links are the same
20161002 15:53:59< vultraz> but yeah, I forgot the !
20161002 15:54:01< celticminstrel> No, they're different lines.
20161002 15:54:05< celticminstrel> Oh wait.
20161002 15:54:11< celticminstrel> I guess I forgot to copy the second one.
20161002 15:54:30< celticminstrel> It's in the same page though, and I think you should be able to guess from what I said?
20161002 15:55:16< vultraz> I see no other missing cases
20161002 15:55:30< celticminstrel> The default in preferences.cpp
20161002 15:55:51< vultraz> anything else?
20161002 15:55:59< celticminstrel> Just those two.
20161002 15:57:22-!- irker764 [~irker@uruz.ai0867.net] has joined #wesnoth-dev
20161002 15:57:22< irker764> wesnoth: Charles Dang wesnoth:master 16331d6bb0fc / src/ (ai/actions.cpp game_preferences.cpp): Fixup ffe7884f533 https://github.com/wesnoth/wesnoth/commit/16331d6bb0fc00473e20e841779ae941a5c1dc07
20161002 16:00:33-!- Kwandulin [~Miranda@p200300760F2C716F9C94B593184288B3.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161002 16:14:03< irker764> wesnoth: mattsc wesnoth:master 371b9b67ec51 / data/ai/lua/ai_helper.lua: Lua AI helper functions: remove attacks/moves on failed action https://github.com/wesnoth/wesnoth/commit/371b9b67ec51bae17ebedba44d6906983fc49915
20161002 16:14:05< irker764> wesnoth: mattsc wesnoth:master 52826a3824ec / data/ai/lua/ca_high_xp_attack.lua: High XP attack CA: do not try to attack petrified enemies https://github.com/wesnoth/wesnoth/commit/52826a3824ecbe32e8a59a0b095afecb8ce8d25a
20161002 16:19:27< irker764> wesnoth: Charles Dang wesnoth:master ef3188056233 / src/ (3 files in 2 dirs): MP Lobby: refactored out the legacy_result stuff https://github.com/wesnoth/wesnoth/commit/ef31880562331e33a970b88d03a2c533372faca0
20161002 16:25:00< vultraz> can't use such methods in the titlescreen, though, since it's different
20161002 16:25:11< celticminstrel> ?.
20161002 16:25:25< vultraz> retvals
20161002 16:26:43< vultraz> I thought one could just set custom revals on all the buttons, except for certain ones you want to draw over the dialog, which couldbe handled in callbacks 
20161002 16:26:48< vultraz> before setting the retval
20161002 16:27:11< vultraz> but I looked at your code and you're doing this complex thing with a loop and REDRAW_BACKGROUND
20161002 16:27:35-!- tad_ [~tadcarluc@173.217.65.103] has joined #wesnoth-dev
20161002 16:27:39< vultraz> maybe I'll see if I can refactor it to use retvals
20161002 16:27:51< celticminstrel> Speaking of REDRAW_BACKGROUND, maybe you should close and reopen the lobby after viewing prefs.
20161002 16:27:59< celticminstrel> No, there's a reason for the titlescreen loop.
20161002 16:28:25< vultraz> that being?
20161002 16:28:33< celticminstrel> I mean you can still use window set_retval if you want, but don't remove the loop.
20161002 16:29:06< celticminstrel> It's there to ensure the titlescreen updates its layout if the window is resized.
20161002 16:29:23< celticminstrel> (Which is behaviour that might also be wanted in the lobby.)
20161002 16:29:30< vultraz> invalidate_layout would do the same thing
20161002 16:29:34< celticminstrel> (Though if we do that we need to be able to save the chat log.)
20161002 16:29:36< celticminstrel> No it wouldn't.
20161002 16:29:41< vultraz> lobby does that..
20161002 16:29:56< celticminstrel> invalidate_layout doesn't change the selected [resolution].
20161002 16:30:06< vultraz> ...really?
20161002 16:30:08< celticminstrel> For that you need to close the dialog and reopen it.
20161002 16:30:09< vultraz> I thought it did
20161002 16:30:12< celticminstrel> Really.
20161002 16:30:24< celticminstrel> The [resolution] is selected at build time.
20161002 16:30:38< celticminstrel> (The build referenced by post_build.)
20161002 16:30:39< vultraz> fun!
20161002 16:31:01< celticminstrel> Of course, it's not so simple to just copy the titlescreen mechanism over to the lobby.
20161002 16:31:11< celticminstrel> Unlike the titlescreen, the lobby has state that needs to be preserved.
20161002 16:31:26< vultraz> (though for the record, I dislike the fact that we use [resolution] instead of relative sizes at all)
20161002 16:31:37< vultraz> i don't think it's ever preserved
20161002 16:32:23< vultraz> sadly
20161002 16:32:26< celticminstrel> Huh?
20161002 16:32:30< vultraz> would be nice if chat was saved
20161002 16:32:44< celticminstrel> I disagree.
20161002 16:32:58< celticminstrel> I don't want to see the chat log from the last time I logged in.
20161002 16:33:07< vultraz> so if you go to create a game and return to lobby you still see chat
20161002 16:33:13< celticminstrel> However, if I haven't logged out, the chat log should be there.
20161002 16:33:20< celticminstrel> Ah, yeah, in that case it would make sense to preserve it.
20161002 16:33:43< vultraz> i think it disappears
20161002 16:33:47< vultraz> haven't really paid attention
20161002 16:34:11< vultraz> most optimal solution would be that chat is stored on the serve
20161002 16:34:13< vultraz> r
20161002 16:34:44< vultraz> so we'd just be like, server, send chatlog
20161002 16:36:22< celticminstrel> I don't think that makes much sense.
20161002 16:36:28< tad_> Nor do I.
20161002 16:36:38< celticminstrel> In particular it means you'd get chatter from while you were playing.
20161002 16:37:12< tad_> I could see some sort of p2p where new joiners get SOME recent chat when joining.
20161002 16:38:54< mattsc> celticminstrel: I have to run off again, but the comment you make on the ai_helper commit brings up an interesting point:
20161002 16:39:20< tad_> mattsc, did you see the forum question about experimental ai?
20161002 16:39:43< mattsc> On the C++ side, failure to change the gamestate (and thus the potential for infinite loops) is handled by black-listing the CA, but apparently this does not happen for the high-XP CA.
20161002 16:40:15< mattsc> I need to test if this is generally the case not for Lua CAs, or something specific here.
20161002 16:40:19< tad_> ouch?
20161002 16:40:22< mattsc> s/not/now
20161002 16:41:03< mattsc> tad_: yes, I did, but since the question was not about the AI itself but about experience with using it in campaigns, I do not really have anything to say about it.
20161002 16:42:11< tad_> OK. I was going to post a comment but wanted to let you have a chance: it is experimental, that means it can be removed without warning.
20161002 16:42:36< vultraz> celticminstrel: it's the lobby... why not see everything :|
20161002 16:42:59-!- Kwandulin [~Miranda@p200300760F2C716F9C94B593184288B3.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161002 16:43:02< celticminstrel> I personally have no interest (usually) in stuff that happened when I wasn't around.
20161002 16:43:03< mattsc> tad_: Well, I don’t expect that we’ll remove it.  But the behavior could be changed more than subtly in the future.  :)
20161002 16:43:23< tad_> exactly
20161002 16:43:50< mattsc> I’ll be afk for the next hour or so.  I’ll check on the logs when I get back.  Bye for now.
20161002 16:45:08< mattsc> Actually, one more comment: the non-default AI parts of the ExpAI are entirely written in Lua.  So it is always possible to preserve whatever state one wants for one’s campaign.
20161002 16:58:34< tad_> ty
20161002 17:03:50-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20161002 17:03:50-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Remote host closed the connection]
20161002 17:06:56-!- trewe [~trewe@2001:8a0:d111:bd01:936f:a116:597:ebda] has quit [Read error: Connection timed out]
20161002 17:22:06< tad_> OK. I'm back to strcmp vs strcoll and how we're damned if we do and damned if we don't. The 'correct' solution is, like Boost, to setlocale every time. That means putting setlocale back into our Lua, changing back to strcoll, and wrapping any places we use < or <= on strings to setlocale("C") to change strcoll into strcmp correctly.  Comments? Concerns?
20161002 17:26:40-!- louis94 [~~louis94@91.178.241.115] has joined #wesnoth-dev
20161002 17:29:23< celticminstrel> So when you say < or <= on strings, you mean in Lua code, right?
20161002 17:29:32-!- ToBeCloud [uid51591@wikimedia/ToBeFree] has joined #wesnoth-dev
20161002 17:34:38< tad_> celticminstrel, correct.
20161002 17:36:03< tad_> Which reminds me .. the only use of strcoll in C++ is for topic sorting in Help and it fails to setlocale so there's a bug there.
20161002 17:36:37< tad_> s/and it fails/and if it fails/
20161002 17:36:57< celticminstrel> We can probably change that to use the function defined in gettext.hpp (which maybe should be moved to a better place as well).
20161002 17:37:19< celticminstrel> So how do you propose to surround Lua string comparisions with setlocale calls without altering the Lua source?
20161002 17:37:51< tad_> By altering the *.lua call sites.
20161002 17:38:32< celticminstrel> Oh, I guess that makes sense.
20161002 17:39:52< celticminstrel> What's that about "putting setlocale back"?
20161002 17:40:43< tad_> celticminstrel, we intentionally remove it during the constructor 
20161002 17:40:53< celticminstrel> ???
20161002 17:41:39< tad_> There is a loop removing most of the Lua "os" module and setlocale is not in the 'except for these' list
20161002 17:43:08< celticminstrel> Oh that. Is there some reason why it should be?
20161002 17:43:48< tad_> Probably. I'll have to think about the removed functions.
20161002 17:44:55< shadowm> Lua must not have access to functions that alter the process' state in permanent and unexpected ways.
20161002 17:46:03< tad_> shadowm, exactly.
20161002 17:46:57< shadowm> Good, I'm glad to see allowing os.setlocale is out of the question then.
20161002 17:47:00< tad_> shadowm, setlocale, however, is a required unexpected and permanent change and if it causes OOS fix the OOS don't randomly break things by removing setlocale on SOME palces and not others.
20161002 17:47:47< tad_> So if setlocale is not allowed then we need to document that < and <= for strings in Lua is not supported and can cause OOS problems.
20161002 17:49:13< shadowm> And/or add a locale-independent (read: ASCII) implementation of the affected functions/operators.
20161002 17:50:33< shadowm> That's the only way that really makes sense unless you can somehow get all participants to agree on communicating each other's locales _and_ having the exact same locale data installed (and the last point is obviously out of our control).
20161002 17:50:34< tad_> shadow So you say we need to make a wesnoth.strcmp function for comparing non-translated strings and document that they cannot be compared using < or <= **EVER** even by accident inside Lua
20161002 17:51:17-!- hk238 [~kvirc@unaffiliated/hk238] has quit [Quit: http://www.kvirc.net/ 4.9.2 Aria]
20161002 17:51:18< celticminstrel> I'm not sure, can string comparison be overridden in the string metatable?
20161002 17:51:26< tad_> celticminstrel, no
20161002 17:51:42< celticminstrel> So adding "string.__lt" or whatever would have no effect?
20161002 17:51:46< vultraz> uh... are we getting rid of string comparison in lua?
20161002 17:51:50< celticminstrel> (Since the global string table is also the string metatable.)
20161002 17:52:54< tad_> celticminstrel, ok .. "it depends" .. but so far I've been looking at the < and <= operators and they don't care .. they use strcoll. I'll re-check
20161002 17:53:54< celticminstrel> I'll check the Lua documentation and see if it says anything.
20161002 17:53:59< tad_> vultraz, Right now we do the probably-right-thing for non-translated strings, and the definitely-wrong thing for translated strings. Originally Lua reversed that.
20161002 17:55:26< tad_> shadowm, setlocale is a permanent state change on all C and C++ programs. Any locale-specific work which fails to do setlocale before proceeding is a bug.
20161002 17:55:44< shadowm> We simply can't support comparing arbitrary strings across the network using locale-dependent functions if that opens up the possibility of two machines with the same locale disagreeing on specific points like whether two UTF-8 sequences represent the same character sequences or not.
20161002 17:56:12< tad_> "with the same locale" is the thing.
20161002 17:56:32< shadowm> Not necessarily.
20161002 17:56:35-!- Kwandulin [~Miranda@p200300760F2C716F0932A8A913FECDC1.dip0.t-ipconnect.de] has joined #wesnoth-dev
20161002 17:56:59< shadowm> You can have two operating systems configured to use the same locale but with different locale data.
20161002 17:57:10< shadowm> Or one of them might not even be prepared to use that locale.
20161002 17:57:13< tad_> shadowm, which is an unsolvable problem.
20161002 17:57:35< shadowm> In that case you'll still get OOS and won't be able to solve the affected users' problems.
20161002 17:57:40< tad_> Well, the solution is to NEVER use locale-specific functions like strcoll
20161002 17:57:48< celticminstrel> Comparing translated strings should be not only for UI purposes, and not be sent across the network.
20161002 17:58:17< celticminstrel> The help is never sent across the network, so it's safe to use strcoll or whatever there.
20161002 17:58:42< tad_> He's concerned that my "enUS" and your "enUS" collate different so when I compare your unit's name I get < and when you do you get >
20161002 17:58:53< celticminstrel> For anything sent across the network, you should use a standard (eg ascii or whatever) comparison.
20161002 17:59:04< shadowm> Or that I'm es_CL.UTF-8 and you are en_US.UTF-8 but you don't have es_CL.UTF-8 available.
20161002 17:59:05< celticminstrel> And they shouldn't be translated.
20161002 17:59:10< tad_> Not sending the string.
20161002 17:59:15< celticminstrel> You want to be comparing only IDs and such that are not translated.
20161002 17:59:31< tad_> I'm moving or not moving in the AI based upon the strings
20161002 18:00:24< tad_> (1) All translated strings are t_string and can only be == checked in C++
20161002 18:00:42< tad_> (2) All locale-specific work in Boost has setlocale prefacing it
20161002 18:01:04< tad_> (3) The only place that (2) does not occur is in sorting topics for help
20161002 18:01:04< celticminstrel> No - translated strings can be < or <= checked if needed.
20161002 18:01:24< celticminstrel> As long as that comparison has no effect on what is sent across the network.
20161002 18:01:30< tad_> celticminstrel, Not as t_string or I don't see the operator override.
20161002 18:01:49< celticminstrel> tad_: Yeah, currently you'd need to do something likt tstr.string() < tstr.string().
20161002 18:02:09< celticminstrel> But it's possible.
20161002 18:02:10< tad_> celticminstrel, which would be a code smell of the First Order, right?
20161002 18:02:15< celticminstrel> Probably.
20161002 18:02:44< celticminstrel> Maybe that comparison function implemented in gettext.hpp should actually be moved into the t_string class and used to implement < <= > >= operators.
20161002 18:02:58< celticminstrel> Then the help and the Lua t_string metatable can just use that.
20161002 18:03:07< celticminstrel> Or something.
20161002 18:03:10< tad_> Oh, yeah. And be sure it uses Boost string compares!
20161002 18:03:59< celticminstrel> I don't see anything in the Lua reference about whether string comparison can be overridden in its metatable.
20161002 18:04:39< tad_> That still leaves the face that strcoll in Lua may, not may not, want to use the "C" locale. And using strcmp is the wrong answer because it ignores "may".
20161002 18:05:03< tad_> celticminstrel, I can read the code again but I don't think it is.
20161002 18:05:17< celticminstrel> I'm not sure if you looked at the comparison function I keep meantioning, but it uses std::use_facet and std::collate... I think passing a Boost locale object though.
20161002 18:05:40< celticminstrel> I think that means that it ignores the global locale.
20161002 18:05:50-!- gfgtdf [~chatzilla@x4e368fc1.dyn.telefonica.de] has joined #wesnoth-dev
20161002 18:06:19< tad_> celticminstrel, It should be. But I'd prefer using Boost instead of std:: if you're going to use the Boost locale object.
20161002 18:06:37< celticminstrel> If Boost defines its own use_facet and collate, then sure. Whatever.
20161002 18:06:53< celticminstrel> It's entirely possible that it doesn't. I haven't looked closely.
20161002 18:07:31< tad_> If nothing else it eliminates the question. Boost, inside, should set what it can of the std locale for just this reason ...
20161002 18:07:42< celticminstrel> The only reason I can see for that function to be implemented in that file is that get_manager() returns a static object...
20161002 18:08:16< tad_> 'singleton'
20161002 18:08:27< celticminstrel> So in other words... if it was moved to the t_string class... the header would need to define a way to get the Boost locale object.
20161002 18:08:31< celticminstrel> Yes, a singleton.
20161002 18:08:53< celticminstrel> The point is that it's not currently accessible outside the file.
20161002 18:09:36< tad_> Ah
20161002 18:10:42-!- louis94 [~~louis94@91.178.241.115] has quit [Ping timeout: 264 seconds]
20161002 18:11:40< tad_> The thing is, when it comes to setlocale, you can call a library (say SDL) and it can change the locale and forget to reset it. So shadowm's concern, while value, MUST be addressed by (1) NEVER sending translated strings over the wire and (2) ALWAYS calling setlocale before any locale-dependant operation.
20161002 18:12:18< tad_> And that is want I propose to do in the Lua.  Set the locale to "C", do < or <=, restore the locale to what it was.
20161002 18:13:18< shadowm> You expect people to use os.setlocale responsibly.
20161002 18:13:36< tad_> Now, I could be prevailed upon to do a wesnoth.setlocale which does a push/pop and never lets the Lua choose the actual locale value. It's "C" or what Preferences set.
20161002 18:14:19< tad_> shadowm, I expect people who set Lua to "es" when Preferences says "en" to expect bugs and fix their Lua
20161002 18:14:38< shadowm> Same thing I said, different wording.
20161002 18:15:05< tad_> Ah. Misunderstood the use of 'you' there.
20161002 18:16:47< tad_> So .. IFF mainline or core Lua does any string compares (I epxect few do) then I will take a look at wrapping them with save=setlocale("C") and setlocale(save) so strcoll becomes strcmp
20161002 18:18:15< tad_> To "do the Right Thing" a Lua which looks at translated strings would need a wesnoth.getlocale() which I don't think we have .. but it's should usually be safe to use the current locale because it's usually left to the Preferences selection and never changed otherwise.
20161002 18:22:49 * tad_ feels like we're holding another Council of Trent and arguing how many angels can dance on the head of a pin ...
20161002 18:22:56< celticminstrel> It's actually not in Preferences, but that's beside the point.
20161002 18:24:07< tad_> celticminstrel, Oh .. right .. comments say Preferences but it's actually Language on the titlescreen.
20161002 18:24:28< celticminstrel> Lua that works with translated strings uses the comparison function that ignores the global locale, so I don't think you need wesnoth.setlocale at all to do the right thing.
20161002 18:24:53< celticminstrel> The Lua programmer simply needs to make sure they have translated strings rather than basic Lua strings.
20161002 18:25:43< tad_> And use os.setlocale(LC_ALL, "C") before and restore it after on the basic Lua strings.
20161002 18:26:33< tad_> Lua actually appears to assume that you NEVER call setlocale and leave it as "C" from the required default from the C/C++ standards.
20161002 18:27:52< tad_> What is strange is Lua took the time to use strcoll. Most libraries simply screw you completely by using strcmp .. which is what OUR Lua is doing right now
20161002 18:29:20< vultraz> It just occurred to me I haven't seen travis today..
20161002 18:29:37< tad_> Has anyone does a commit?
20161002 18:30:05< vultraz> several
20161002 18:31:16< tad_> Last was 2 hours ago (on master). And I don't see a travis followup for it.
20161002 18:34:35< shadowm> https://travis-ci.org/wesnoth/wesnoth
20161002 18:37:12-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has quit [Ping timeout: 244 seconds]
20161002 18:37:46< tad_> So it's not Travis, it's the IRC robot announcer
20161002 18:46:49< tad_> So, I'm going to let Lua do setlocale, change back to strcoll, and fix and < <= > >= on strings to set/save/restore locale .. unless I here a veto.
20161002 18:46:52< tad_> shadowm, ^
20161002 19:02:01< irker764> wesnoth: Charles Dang wesnoth:master ae663df1f08d / data/gui/window/end_credits.cfg: End Credits: use no-blur version of box_display panel https://github.com/wesnoth/wesnoth/commit/ae663df1f08d17d530d00641984e1b8b1a3c9c2f
20161002 19:02:04< irker764> wesnoth: Charles Dang wesnoth:master 6f7cb3901ebd / src/ (gui/dialogs/title_screen.cpp gui/dialogs/title_screen.hpp wesnoth.cpp): Title Screen: refactored button handling to use dialog retvals https://github.com/wesnoth/wesnoth/commit/6f7cb3901ebde890fa8289af4089e929a15a516a
20161002 19:02:07< vultraz> celticminstrel: ^
20161002 19:03:43< celticminstrel> You missed a now-redundant window.close() on line 378.
20161002 19:03:58< celticminstrel> Basically looks fine though.
20161002 19:04:09< celticminstrel> Wait, sorry, line 374.
20161002 19:04:24< celticminstrel> (It's 378 in pre-commit version of the file.)
20161002 19:05:14< celticminstrel> You could've just used bind on line 379, but whatever.
20161002 19:06:11< celticminstrel> What's the default retval, anyway...
20161002 19:06:27< vultraz> not sure
20161002 19:06:32< vultraz> but it's usually either OK or CANCEL
20161002 19:06:54< celticminstrel> I don't think I like how you moved the loop out of the dialog, honestly.
20161002 19:07:04< vultraz> it was never IN the dialog
20161002 19:07:06< vultraz> just in its class
20161002 19:07:14< celticminstrel> That's what I meant.
20161002 19:07:39< celticminstrel> Leaving it in the class would mean that you don't need the redraw_background getter/setter, I think.
20161002 19:07:44< vultraz> hm
20161002 19:07:46< vultraz> true
20161002 19:07:55< vultraz> I could move it back
20161002 19:08:10< vultraz> might not be worth it
20161002 19:08:19< celticminstrel> "and any regular action simply sets the window's retval and proceeds to the appropriate action." -- Not any action, only actions that cause you to leave the title screen.
20161002 19:08:58< vultraz> ah, true
20161002 19:09:01< celticminstrel> The if statement at lines 788-790 seems redundant, since the dialog has just been newly-constructed.
20161002 19:09:14< celticminstrel> (In wesnoth.cpp)
20161002 19:09:35< vultraz> "we then once again set the flag to true on the next run of the loop so the dialog once again opens properly."
20161002 19:09:41< vultraz> it's redundant on the first run only
20161002 19:09:43< celticminstrel> I think I'd prefer to have the loop in the dialog class, but semantically I guess it's the same.
20161002 19:09:45< celticminstrel> Wrong.
20161002 19:09:57< celticminstrel> The dialog is newly-constructed on each run.
20161002 19:10:14< celticminstrel> So unless there's garbage data in the redraw_background_ member, it's always redundant.
20161002 19:10:29< vultraz> er...
20161002 19:10:30< vultraz> hm...
20161002 19:10:41< vultraz> what's the default initialization value of a bool again?
20161002 19:10:45< celticminstrel> If the dialog was constructed outside the loop, you would be correct.
20161002 19:10:58< celticminstrel> The default initialization value of a bool is the same as all integral types.
20161002 19:11:10< celticminstrel> If static, 0 (ie false). Otherwise, no intialization.
20161002 19:11:18< celticminstrel> ^initialization
20161002 19:11:36< celticminstrel> Where "no initialization" means "whatever happens to have already been in memory at the location assigned to it".
20161002 19:11:41< vultraz> hm
20161002 19:12:11< vultraz> I just realized i might've added that check before i realized i had accidentally forgotten to add the flag to the constructor list.
20161002 19:13:32< vultraz> ahh
20161002 19:13:36< vultraz> yeah it works fine without
20161002 19:13:55< vultraz> first time I've been bitten in the ass by forgotten the member initializer :P
20161002 19:14:04< vultraz> forgetting
20161002 19:14:48 * vultraz fixes documentation
20161002 19:16:30 * tad_ makes a note to discuss adding an option to warn on missing member initializers using default constructors in GCC when (if) he next talks to his friends over there ...
20161002 19:20:13< irker764> wesnoth: Charles Dang wesnoth:master 85a6a5132f16 / src/ (gui/dialogs/title_screen.cpp gui/dialogs/title_screen.hpp wesnoth.cpp): Minor fixups to 6f7cb3901ebd https://github.com/wesnoth/wesnoth/commit/85a6a5132f16b8eca5924253ce2dc7878900394c
20161002 19:20:42< vultraz> thanks for pointing that out
20161002 19:20:53< vultraz> don't need the setter now
20161002 19:23:15< celticminstrel> Could've fixed the typo in the comment too, but whatever.
20161002 19:35:06< tad_> mattsc, This sort of stuff makes me nervious. cf ~/data/ai/lua/generic_rush_engine.lua:380 --> if (max_rating > -9e99) then
20161002 19:37:18-!- Kwandulin [~Miranda@p200300760F2C716F0932A8A913FECDC1.dip0.t-ipconnect.de] has quit [Read error: Connection reset by peer]
20161002 19:48:30< mattsc> tad_: specifically what about it?  FYI, in the newer Lua AIs I generally don’t do it like that any more.
20161002 19:49:03< mattsc> It’s not usually something like ‘if (not best_unit) then …’ — which of course requires a slightly different first assignment of the variable.
20161002 19:49:10< mattsc> s/not/now
20161002 19:49:18< mattsc> That’s the second time today that I have done that!
20161002 19:51:12< mattsc>  Oh, and of course in this case the ‘if’ statement should not have the ‘not’ in it.
20161002 19:51:45< mordante> vultraz, several unneeded conversions, not sure why it compiles for others
20161002 19:55:06< tad_> mattsc, the value -9e99 is so arbitrary what if the result is -9.1e99 ??? seems to be just say if(true) is effectively the same thing and less arbitrary.
20161002 19:55:10< shadowm> mordante: OS and compiler?
20161002 19:55:25< mordante> still Debian stable and gcc
20161002 19:55:46< shadowm> And I guess you still use CMake?
20161002 19:55:53< mordante> indeed
20161002 19:56:11< mattsc> tad_: the evaluation function cannot possibly return anything anywhere close to -9e99.  The value is intentionally chosen to be way smaller than anything that can come out of it.
20161002 19:56:25< tad_> mattsc, on the other side I see "if (value < 9999) then" often and don't have a problem with that. but -90000...90 more 0's...00000.0 .. REALLY?
20161002 19:56:53< mattsc> tad_: I would call that a very arbitrary distinction on your side then.
20161002 19:57:15< shadowm> mordante: IIRC people haven't been taking care of CMake much since I stopped making releases, but I'll see if I can reproduce the issue.
20161002 19:57:49< celticminstrel> Pretty sure tad_ uses CMake, so if there were a universal CMake issue he would've pointed it out.
20161002 19:57:52< shadowm> I'm on Debian sid though, although I have a very bare-bones stable chroot I could use.
20161002 19:57:53< mordante> I can probably fix it myself, but been busy with other things
20161002 19:58:13< shadowm> And this is x86_64 or x86?
20161002 19:58:18< tad_> mattsc, Yes, but I could probably do the match and come up with something like 'this value, times that value, is LONG_MAX' so I limit this value to avoid integer overflow
20161002 19:58:22< shadowm> Or something else entirely?
20161002 19:58:27< mordante> amd64
20161002 19:58:43< shadowm> Okay, same here.
20161002 19:59:20< tad_> mattsc, s/match/math/
20161002 20:01:15< mattsc> tad_: I don’t know what you are saying.  -9e99 is never calculated from anything.  It’s assigned and an approximation of minus infinity.
20161002 20:01:38< mattsc> There are evaluation functions that produce results in excess of +/-9999.
20161002 20:01:51< mattsc> I am using something that cannot possibly ever be reached.
20161002 20:01:59< tad_> mattsc, that's my point. if(true) is an exact comparison to > minus infinity
20161002 20:03:29-!- vultraz [~chatzilla@wesnoth/developer/vultraz] has quit [Ping timeout: 244 seconds]
20161002 20:06:26< mattsc> tad_: sorry, but I am not getting what your actual point is.
20161002 20:07:50< tad_> mattsc, Your intent is to say "If this is greater than -INF then" and the exact representation for that test is "If TRUE then" .. or, more properly, "If not NAN and not -INF then" but Lua does not do that so "true" is correct.
20161002 20:08:33< mattsc> tad_: no, that is not my intent
20161002 20:08:59< mattsc> My intent is to say: “if a valid score has been assigned, then …”
20161002 20:09:24< mattsc> What you are saying is one way of implementing that test.
20161002 20:09:43< tad_> mattsc, so -8.9e99 is 'valid' but -9.1e99 is 'not valid'
20161002 20:09:51< mattsc> no
20161002 20:10:07< mattsc> it could be, but it isn’t
20161002 20:10:39< mattsc> I don’t want to have to worry about whether the minimum possible score might be -999 or -9999 or even -999999.
20161002 20:10:49< tad_> mattsc, Which is why the test for -9e99 makes me nervious. Should it be something like -9999 instead?
20161002 20:11:01< mattsc> (if I change the evaluation functions in the future)
20161002 20:11:25< mattsc> tad_: no, it should not, for the reason I just mentioned.
20161002 20:11:27-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20161002 20:11:49< mattsc> As I said, there are evaluation functions that reutrn scores with abs(score) > 10,000.
20161002 20:13:01< mattsc> tad_: I am not arguing at all that what you are suggesting would be “cleaner”, or whatever the right word here is.
20161002 20:13:05-!- gfgtdf [~chatzilla@x4e368fc1.dyn.telefonica.de] has quit [Ping timeout: 252 seconds]
20161002 20:13:09< tad_> ok. just commenting about it seems strange. and I do see range checks like -9e99<N<9999 ..
20161002 20:13:43< mattsc> Where?
20161002 20:14:29< mattsc> tad_: But other than “you don’t like it” (paraphrased) you haven’t given me an actual reason why I shouldn’t do it this way.
20161002 20:15:29< mattsc> I told you the reason why I (used to) do it that way; if there’s a reason against it, I am happy to change it.
20161002 20:15:33< tad_> mattsc, No reason why not. It's fine code. Just "why -9e99?" why not "-9.9999e100"?
20161002 20:15:51< mattsc> Because the former is fewer letters to type.  ;)
20161002 20:16:26< mattsc> Other than that, no reason.
20161002 20:16:46< mattsc> tad_: as I said, in my newer code I am using true/false comparisons anyway, so it would make sense to adapt this for consistency.
20161002 20:16:56< tad_> mattsc, To be honest, it makes me wonder, if it can go so absurdly negative, but not nearly so positive .. maybe he's afraid he missed a range-sanity check earlier and needs a fallback?
20161002 20:17:36< tad_> mattsc, Well, take my comment as a vote to pause a moment and reflect upon it if you're the the area ever in the future ...
20161002 20:18:33< mattsc> tad_: It cannot go so absurdly negative, that’s the point of choosing that value.  But where did you see that -9e99 < score < 9999 comparison?
20161002 20:19:02-!- gfgtdf [~chatzilla@x4e368fc1.dyn.telefonica.de] has joined #wesnoth-dev
20161002 20:19:43< tad_> mattsc, AI, obviously. I just scanned ~/data/ai/lua/ so somewhere in there.
20161002 20:20:18< mattsc> tad_: the other thing you might not have heard me say yet (other have many times, I know that), is that I have no CS background and a lot of the older code was me trying to figure out how things work.
20161002 20:20:24< tad_> I'm codereading all /[<>][=]?/ in *.lua looking for string compares
20161002 20:20:45< mattsc> So some of this stuff is simply left over from back then.
20161002 20:21:02< mattsc> I do clean things up when I come across them these days, but it’s easy to miss things.
20161002 20:21:04< tad_> mattsc, NP with that. I have the S in CS and I rarely use it. CS is not programming.
20161002 20:22:50< mattsc> tad_: so anyway, not trying to be argumentative here; just trying to figure out if there’s a real potential issue with it, or if it just doesn’t look right because it’s arbitrary …
20161002 20:23:14< tad_> In 3 or 4 decades I think, once I left uni, I did exactly ONE formal proof of correctness.
20161002 20:23:48< tad_> mattsc, Just doesn't look right. Makes me wonder why, when 'true' works just as well and is faster
20161002 20:24:29< mattsc> tad_: because I did not know any better 3 or 4 years ago when I started meddling with AI code. Simple as that.
20161002 20:24:41< mattsc> tad_: FYI, this is how it looks when I do the same thing now:  https://github.com/wesnoth/wesnoth/blob/master/data/ai/lua/ca_high_xp_attack.lua#L290
20161002 20:25:27< tad_> mattsc, Saw that .. probably what made me make a comment.
20161002 20:26:21< mattsc> Anyways, I took down a note to look into this once I am done with all the MAI and high-XP CA stuff that is actually broken.
20161002 20:26:23< tad_> mattsc, I'm not saying it's wrong, just something to consider if you're ever in the neighborhood
20161002 20:26:47< mattsc> tad_: yep, sounds good; see my last comment.
20161002 20:26:48< tad_> mattsc, Not suggesting you actually go looking
20161002 20:27:14< mattsc> tad_: and I do appreciate the pointer.
20161002 20:28:21< tad_> These are floats. If you ever have extra Ibuprofen you want to use up I can point you to some papers on how evil floats are and all the tiny ways they can mess you up ...
20161002 20:29:37 * celticminstrel guesses the root of floating-point evil is binary.
20161002 20:29:51< celticminstrel> If it was BCD for example it would probably have less surprises.
20161002 20:30:03< tad_> celticminstrel, loss of precision would be a major factor
20161002 20:30:26< mattsc> tad_: I’ll pass for now.  ;)  But I do know that I have used things like ‘if (abs(x) < 1e-6)’ because ‘if (x == 0)’ does not work.
20161002 20:30:55< tad_> Have you ever wondered why ((float)1.0 - (float)1.0) != 0.0 sometimes and not others?
20161002 20:31:40< mattsc> *does not work reliably
20161002 20:31:42< tad_> mattsc, there you go. spawn of the Devil .. float! .. get the behind me!
20161002 20:31:52< mattsc> :)
20161002 20:32:53< tad_> The value you used (1e-6) has an exact value called 'epsilon' and it varies depending on whose float you're using.
20161002 20:33:20< tad_> You'll see 'epsilon' a lot in those papers needing Ibuprofen .. 
20161002 20:35:15-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has joined #wesnoth-dev
20161002 20:35:45< mattsc> tad_: yeah, I’m (generally) aware of that.  I don’t know CS or coding, but I do know a decent amount of maths.  So I was actually wondering if something like that is what you were getting at with your original comment.
20161002 20:36:00< tad_> celticminstrel, BCD? Oh am I glad we don't use BCD and more which makes me Real Glad we don't have to worry about EBCDIC for all this setlocale work I'm looking into ...
20161002 20:36:56< tad_> mattsc, Sort of. I take '-9e99' to mean "I wanted to use -INF but Lua doesn't know -INF so this will do"
20161002 20:37:12 * celticminstrel seems to recall IEEE-759 or whatever the number having BCD.
20161002 20:37:16< celticminstrel> ^number is
20161002 20:37:24< tad_> mattsc, But any non-NAN compard to -INF is TRUE
20161002 20:39:11-!- prkc [~prkc@46.166.138.134] has joined #wesnoth-dev
20161002 20:42:05< tad_> mattsc anyway, I'm looking for strings using < and <= and not finding any which is good.
20161002 20:42:54< mattsc> tad_: okay; good.  And sounds like we’re in agreement on the other topic.
20161002 20:44:27< tad_> mattsc, sure .. just we don't want it to go too quiet in here or the lurkers will wonder what is so major we're working on and not talking `)
20161002 20:44:56< mattsc> Ha!
20161002 20:46:10< mattsc> celticminstrel: So there’s a problem.  It appears that if the only thing a Lua CA does is an ai.stopunit_moves on a unit that already has 0 MP, the CA does not get blacklisted as it should.
20161002 20:46:16< mattsc> Even though ai.check_stopunit_moves shows that the gamestate did not change.
20161002 20:46:54< celticminstrel> Huh?
20161002 20:47:25< celticminstrel> Okay, so stopunit_moves sets MP to 0, right?
20161002 20:47:31< celticminstrel> (Or something equivalent.)
20161002 20:47:33< mattsc> yes
20161002 20:47:47-!- JyrkiVesterinen [~JyrkiVest@78-27-109-121.bb.dnainternet.fi] has joined #wesnoth-dev
20161002 20:47:51< JyrkiVesterinen> 20161002 20:36:56< tad_> mattsc, Sort of. I take '-9e99' to mean "I wanted to use -INF but Lua doesn't know -INF so this will do"
20161002 20:48:07< mattsc> A CA that does not change the gamestate when it is executed should be blacklisted.
20161002 20:48:09< JyrkiVesterinen> Lua does know INF. There is the constant math.huge.
20161002 20:48:13< celticminstrel> I guess it needs to check that the unit's MP are not already 0. Sounds like a simple fix once you find the correct place.
20161002 20:48:18< mattsc> That’s the safeguard against infinite loops.
20161002 20:48:20< celticminstrel> JyrkiVesterinen: I noticed that, but is that really INF?
20161002 20:48:24< JyrkiVesterinen> Use -math.huge to get negative infinity.
20161002 20:48:40< celticminstrel> My impression was that math.huge is the largest value less than INF.
20161002 20:48:52< celticminstrel> ...though I guess that does suggest that math.huge+1 would be INF...
20161002 20:49:40< tad_> mage.huge + math.epsilon == +INF
20161002 20:49:47< JyrkiVesterinen> Lua documentation guarantees that math.huge returns HUGE_VAL.
20161002 20:49:49< mattsc> celticminstrel: no, this is something that should be built into the main_loop mechanism.  If the gamestate did not change, the CA is blacklisted and not evaluated any more until the end of the AI turn.
20161002 20:49:56< tad_> but don't actually try it because it should throw
20161002 20:50:07< mattsc> If that does not work, I’d call that a blocker bug.
20161002 20:50:39< celticminstrel> mattsc: What I meant was that it sounds like the underlying C++ implementation of stopunit_moves is marking the gamestate as changed even though it hasn't been, but maybe I'm misunderstanding the situation.
20161002 20:50:41< JyrkiVesterinen> And HUGE_VAL is guaranteed to be infinity: http://en.cppreference.com/w/c/numeric/math/HUGE_VAL
20161002 20:51:00< celticminstrel> Oh... so why isn't it called INFINITY then. :|
20161002 20:51:21< tad_> because it's epislon away from infinity
20161002 20:51:21< celticminstrel> I think std::numeric_limits does call it that, at least.
20161002 20:51:29< mattsc> celticminstrel: if you do a check_stopunit_moves, it shows that the gamestate did NOT change.  So it is rather that it is not checked correctly.
20161002 20:51:37< celticminstrel> I see.
20161002 20:51:53< mattsc> celticminstrel: I am pretty sure that this used to work.  But I have not had time to check yet if it worked in 1.13.4.
20161002 20:51:57< celticminstrel> I'm not sure what the issue would be then.
20161002 20:52:12< JyrkiVesterinen> There is an INFINITY macro as well. It was added in C99.
20161002 20:52:17< celticminstrel> How do you know that it shows the gamestate didn't change, BTW?
20161002 20:52:51< mattsc> Because I set up the test case so that it does not.  Also because the check_* function above tells me that it did not.
20161002 20:53:11< tad_> JyrkiVesterinen, Yeah, well, as I said floats are evil. The manifest constants and standards changes are all attempts to limit that evil and change as we find out more about how deeply evil floats are
20161002 20:53:52< JyrkiVesterinen> IMO, floats are very well designed. They can represent a massive range of values, and they adapt their precision with magnitude.
20161002 20:54:05< mattsc> celticminstrel: I’ll set up a test case to see whether it worked in 1.13.4 or before  in a little while.  That will tell use whether it likely got broken in the refactoring, or was already a problem before then.  But for now … (guess what), I’m off again.
20161002 20:54:28< tad_> JyrkiVesterinen, which is all well and good until you get to the edge cases
20161002 20:55:03< JyrkiVesterinen> Still, I think there was simply no way to design floats any better than they were designed.
20161002 20:55:18< JyrkiVesterinen> Edge cases were pretty much unavoidable.
20161002 20:55:53-!- atarocch [~atarocch@93.56.160.28] has quit [Remote host closed the connection]
20161002 20:56:03-!- ChipmunkV [~vova@static-89-94-113-91.axione.abo.bbox.fr] has quit [Quit: ChipmunkV]
20161002 20:56:50< tad_> JyrkiVesterinen, well, at some level all float values are edge cases which is why we need to worry about epsilon for, for example, comparisons to 0.0
20161002 20:57:31< JyrkiVesterinen> More generally, exact comparisons of real numbers.
20161002 20:58:10< JyrkiVesterinen> If you don't have infinite precision, different calculations can easily give you slightly different values even if they should mathematically give the same value.
20161002 20:58:34< JyrkiVesterinen> That problem affects all possible representations of real numbers. Not just IEEE 754 floats.
20161002 20:59:15< tad_> Which is why those papers I was talking about a while ago give you headaches .. like "who cares, it's not like we're normally calculating orbital trajectories or controlling nuclear reactors, right?"
20161002 21:00:13< tad_> until someone points out that some nuclear reacots use NPM and your back starts to crawl with the implications of THAT!
20161002 21:00:49< JyrkiVesterinen> Orbital trajectories and nuclear reactions should be calculated with infinite precision if possible. Using floats there is misuse.
20161002 21:06:03< tad_> And now you know what we're so glad to see integer div and integer rem operators appear in Lua ... not that I'd want my reactor to run Lua but still
20161002 21:08:22 * tad_ chuckles .. here I was concerned about -9e99 and the answer is "42" .. ca_messenger_attack "if cost >= 42424242 then return end"  ROFL
20161002 21:08:33< JyrkiVesterinen> I know of one real-world problem that was caused by Lua's lack of support of integers.
20161002 21:10:20< JyrkiVesterinen> Two games I have worked on support score synchronization via the cloud. Conflicts are possible with synchronization: the player can e.g. pass certain levels on device A and other levels on device B, and the game can only later know that progress was made in both devices.
20161002 21:11:00< JyrkiVesterinen> In a conflict situation, the game displays some information about the two game states the player can choose. The information includes the combined score from all the levels.
20161002 21:11:47< JyrkiVesterinen> In addition to that, we have configured Lua to use single-precision floating-point numbers, because on many mobile devices double-precision support is emulated or at least extremely slow.
20161002 21:12:05< JyrkiVesterinen> (Or so it was, anyway. The situation may well have improved since that decision was made.)
20161002 21:12:37< JyrkiVesterinen> The largest integer that a single-precision float can represent exactly is 16 777 216, and the total score was able to exceed that.
20161002 21:13:23< JyrkiVesterinen> Sooo, the games actually perform the total score calculation in C++ code, and pass the result to Lua as a string, since a number wouldn't be accurate enough.
20161002 21:13:43< tad_> JyrkiVesterinen, One of the things I like about Lua is it does so much so clearly. But there are still hiccups like the integer/float interface which I'm still not sure is really worked out properly and this hitch about using strcoll and not doing a lot of handwaving about setlocale in the docs for comparing strngs ...
20161002 21:13:44< JyrkiVesterinen> All that would have been avoidable if we had proper integers instead.
20161002 21:14:59< celticminstrel> Single-precision is what "float" typically is (at least), right?
20161002 21:15:19< tad_> celticminstrel, correct answer to that is "it depends"
20161002 21:15:20< JyrkiVesterinen> Yes. float = single precision, double = double precision-
20161002 21:15:30< JyrkiVesterinen> Lua uses double precision by default.
20161002 21:15:33< celticminstrel> tad_: "typically"
20161002 21:15:54< mattsc> tad_: https://github.com/wesnoth/wesnoth/blob/master/src/pathfind/pathfind.hpp#L64
20161002 21:17:29< tad_> mattsc, Now you have my wife looking strangely at her husband wondering why he's laughing
20161002 21:18:11< mattsc> Just pointing out that while I put the 42424242 into the messenger_attack, it’s not my doing.  :)
20161002 21:18:31< mattsc> I’d like to take credit for it, but alas ...
20161002 21:19:23< tad_> mattsc, I'd have used 43434343 and shown my age ... "What is the answer to life, the universe, and everything?" "43" "What was the question?" "What is 6 times 7." "I always knew there was something a bit off about the universe!"
20161002 21:20:10< mattsc> Yeah, well, that’s because the question is “what is 6*9”.  ;)
20161002 21:20:35< tad_> Bah. I should check the referencs and not depend upon grey matter.
20161002 21:21:28< mattsc> hehe
20161002 21:28:08< tad_> mattsc, YEAH! There is a string going into a >= expression and (YES!) it was run through tonumber() instead of hoping it gets autoconverted correctly. Someone was on the ball.
20161002 21:29:44< mattsc> tad_: good
20161002 21:30:41< mattsc> celticminstrel: so the CA being blacklisted does already not work in 1.13.4 and 1.13.0.
20161002 21:41:17< mattsc> celticminstrel: oh, one more thing: if the CA just does not do anything, it does get blacklisted correctly.  So it has something to do with the stopunit command.
20161002 21:47:20-!- zookeeper [~lmsnie@wesnoth/developer/zookeeper] has quit [Ping timeout: 244 seconds]
20161002 21:47:55< tad_> what are *fai files? should I worry about them when thinking about Lua?
20161002 21:48:48< celticminstrel> No.
20161002 21:48:56< celticminstrel> Those are FormulaAI, which means WFL code.
20161002 21:50:01< tad_> ty. thought so but wanted to be sure.
20161002 22:03:31 * tad_ wipes his brow.
20161002 22:04:33< tad_> Whew. Done. No strings compared using < > <= or >= in any mainline/core *.lua files. So now to add setlocale and test that and restore strcmp to strcoll.
20161002 22:06:00-!- horrowind [~Icedove@2a02:810a:8380:10a8:21b:fcff:fee3:c3ff] has quit [Quit: horrowind]
20161002 22:14:28< tad_> celticminstrel, To answer your question: NO, Lua does not use metatables for lt and le for num-to-num < or <= nor does it for string-to-string but it DOES use it in all other cases such as number-to-string string-to-userdata etc.
20161002 22:20:30-!- irker764 [~irker@uruz.ai0867.net] has quit [Quit: transmission timeout]
20161002 22:29:53< tad_> celticminstrel, And .. YEAH! .. gtgfdf added metatable methods for lt le eq for t_strings in Lua .. so the ONLY issue is "C" locale strings .. which explains why he though changing strcoll to strcmp was the right way to go.
20161002 22:30:14< celticminstrel> Pretty sure I've said this multiple times. :P
20161002 22:36:30< gfgtdf> was any progress made on the decision whether to update to luagit or lua 5.3 ?
20161002 22:36:40< gfgtdf> juajit*
20161002 22:37:45< celticminstrel> Heh.
20161002 22:42:05-!- Bonobo [~Bonobo@2001:44b8:254:3200:2d2b:4929:31a:e4c] has joined #wesnoth-dev
20161002 22:45:02< tad_> gfgtdf, I am proceeding with reverting or refactoring all Wesnoth-specific changes with the Lua sources. Unless told otherwise, when done I will proceed to upgrade to Lua 5.3.3. I believe the consensus sentiment is to get the integer/float changes of 5.3.3 and re-consider LuaJIT when it upgrades to Lua 5.3.
20161002 22:46:59< gfgtdf> tad_: i actuall like the thought of luajit, but i just read this code: http://luajit.org/ext_ffi.html and wonder whtehr luajit as actuall save to use as an addon language if it supports that stuff. Maybe it can be disables, have to read on
20161002 22:47:47< tad_> celticminstrel, Saying it and seeing it is different. It also makes the issue a bit more thorny and gfgtdf's changes actually make changing back to stdcoll more important.
20161002 22:48:39< tad_> gfgtdf, ffi can be disabled as we currently do "os" modules. But it's good to research and carefully consider because it's a major change.
20161002 22:49:39< tad_> gfgtdf, At present, we can go either way .. it should be possible to build 5.3.3 into a release and make a personal fork for JIT 5.2.3 for testing and experimentation
20161002 22:50:35< tad_> gfgtdf, cave generator in LuaJIT would probably be sceaminly fast compared to vanilla 5.2.3
20161002 22:50:54< gfgtdf> tad_: we cannot easily go 'back' to 5.2.3 once we put  5.3.3 into a release. so that doenst sound lieka good plan to me
20161002 22:52:27< tad_> gfgtdf, At present, we can, because there is no 5.3 Lua code. But I will call the question again in a few days for final debate when I feel I'm ready. First we'll probably debate the PR I'm preparing which does the revert and refactor work.
20161002 22:52:50< tad_> gfgtdf, If you want to see where I'm at, presently, it's in my GL_Lua branch on my personal fork
20161002 22:53:11< gfgtdf> tad_: yes but once we release a wesnoth version with lua 5.3 there can be 5.3 code.
20161002 22:53:36< tad_> gfgtdf, of course.
20161002 22:54:22< tad_> gfgtdf, then the question becomes waiting for LuaJIT to catch up. My reading is it's "in process" but no date set. They'd best get crackin' through because Lua 5.4 could appear ...
20161002 23:06:18-!- JyrkiVesterinen [~JyrkiVest@78-27-109-121.bb.dnainternet.fi] has quit [Quit: .]
20161002 23:47:06-!- wedge009 [~Thunderbi@60-241-236-92.static.tpgi.com.au] has joined #wesnoth-dev
--- Log closed Mon Oct 03 00:00:32 2016