IRC log for #bzflag on 20170129

00:24.19macsformehmm, http://industriousone.com/topic/multiple-solutions-sharing-projects-premake-dev
00:24.38macsformeso maybe we could just leave the existing .sln files, and solve that issue
00:25.15macsformealso I found a premake function called location(), whereas I had been using basedir(), so I might be able to straighten out the project paths too
00:28.57macsformethere's also this: https://github.com/premake/premake-core/wiki/includeexternal
00:30.12macsformeor this: https://github.com/premake/premake-core/issues/122#issuecomment-114594825
00:30.27macsformeso it sounds doable
00:49.27*** join/#bzflag BZnotify (~BZnotify@192.30.252.45)
00:49.27BZnotify[13bzflag] 15blast007 closed pull request #63: fix warnings (062.4...062.4_VC2015_warnings) 02https://git.io/vDULS
00:49.27*** part/#bzflag BZnotify (~BZnotify@192.30.252.45)
00:49.54jh`macs are not made for playing...
00:50.42jh`they are overexpensive trash really
00:50.53*** mode/#bzflag [+o blast007] by ChanServ
00:51.17*** mode/#bzflag [+q jh`!*@*] by blast007
00:51.23*** mode/#bzflag [-o blast007] by blast007
00:51.56JeffMblast007: so that was the right way to do it?
00:52.10blast007right way to do a PR?
00:52.45JeffMYeah with a branch
00:53.01blast007it worked fine
00:53.24JeffMThen I deleted the branch
00:54.32*** part/#bzflag jh` (~Janne@85-23-152-190.bb.dnainternet.fi)
01:08.51blast007http://flatpak.org/
01:10.08blast007(was just mentioned in #debian-games)
01:10.34blast007< pabs> from #debian-devel <smcv> I want to publish at least some of debian as flatpaks, starting with games
01:11.27blast007not sure how it differs to snaps
01:18.07JeffMIs flatpack in Debian
01:19.10blast007nope :)
01:19.47blast007looks like snapd will be included with the next Debian release
01:50.48blast007hmm, is there a point to having .sln files for each plugin in our official source tree?  or is it enough to just have one in SAMPLE_PLUGIN?
01:59.16macsforme<PROTECTED>
01:59.46macsformeoh, nvm... I get it now
02:00.07macsformeI thought you were saying it links to the debug version when building release
02:04.09macsformeJeffM: https://www.irccloud.com/pastebin/F9igUdP8/ ... I think I saw those too... any idea how to fix that?
02:29.40macsforme<PROTECTED>
02:29.54macsformeproject folders should work... I just had the express version of VC2010 so I couldn't test
02:30.14macsforme<PROTECTED>
02:30.32macsformecan you elaborate on that? premake generates the bzflag.rc file so we don't have to update the version manually
02:34.10macsformeor rather, it pulls in the template version and makes substitutions, then writes it out
02:49.48JeffMmacsforme: folders wont' get created if there isn't a filters file.
02:50.08JeffMpremake actualy creates the .rc file? what if you want your own resources?
02:50.13JeffMahh
02:50.21JeffMit should go in a res or resources project folder
02:50.45JeffMit needs to keep the user resources, like icon and stuff, but it's ok to do the version thing
02:51.09JeffMthere can be a lot more than versions and icons in a res file
02:51.20JeffMdoes it support resx files?
02:57.35macsformeit probably supports whatever visual studio supports... in premake it's literally just "file "bzflag.rc"
02:58.02JeffMso it supports all languages that visual stuido supports?
02:58.18JeffMit must know the format of the .rc to update the version info
02:58.28JeffMa resx is for mixed mode code, and has a different format
02:58.34JeffMor does it just search and replace?
02:58.55macsformeI made a function to search and replace... it's used for several files
02:59.11JeffMahh so you have to do that in the script, it's not built in?
03:00.34macsformeI poked around trying to figure out how to make a .rc file, but there didn't seem to be much good information (and you apparently can't edit them in visual studio 2010 express edition), so I just added the .rc file that we already have and it worked
03:00.52JeffMno you can't, that's why express sucks
03:01.08JeffMand why bzflag needs to get off of it and onto community editions
03:01.41macsformehttps://github.com/macsforme/bzflag/blob/premake/premake5.lua#L495-L513
03:02.02JeffMyeah that'll work for simple replacments
03:03.00JeffMblast007: they person who said they wanted flatpaks for games, what postion do they hold in the debian high court?
03:07.25blast007< smcv> by which I mean one day I'll have the time and energy
03:07.25blast007<PROTECTED>
03:08.25blast007so, some time, some day, in the distant future, flakpak might be a thing
03:09.49blast007JeffM: is there a need for the .sln files in individual plugins (aside from SAMPLE_PLUGIN) ?
03:10.12JeffMonly if you want to develop a single plugin
03:10.23JeffMand only build that one
03:10.31JeffMmakes copying them easier
03:10.48JeffMI would not want to build fullbuild just to edit one plugin
03:21.17JeffMalso people can build one off plugins on windows, they do not require full bzflag source
03:21.44JeffMthat's a huge advantage when dealing with third party plugins
03:22.16JeffMwhy would I even need the client sources if all I want to do is build a single plug-in
03:22.25*** join/#bzflag jnoob22 (~jnoob@unaffiliated/jnoob22)
03:22.53blast007k.  so I'll finish upgrading all those to 2015 tomorrow.
03:23.02JeffMwhat is left?
03:23.09JeffMoh the plugins
03:23.24JeffMa search and replace would do it
04:13.18*** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001)
04:14.46*** join/#bzflag Shuist (~Shuist@ppp203-122-213-220.static.internode.on.net)
04:35.35*** join/#bzflag Void7 (uid197664@gateway/web/irccloud.com/x-teblfqpiqvbmallw)
06:45.11*** join/#bzflag BZnotify (~BZnotify@192.30.252.42)
06:45.11BZnotify[13bzflag] 15JMakey pushed 2 new commits to 062.4: 02https://git.io/vDU8j
06:45.11BZnotify13bzflag/062.4 14c08dc00 15Jeff Makey: Distribute new MSVC project files.
06:45.11BZnotify13bzflag/062.4 1440dbb74 15Jeff Makey: Cast time_t to long long unsigned to match %llu format.
06:45.11*** part/#bzflag BZnotify (~BZnotify@192.30.252.42)
09:12.39*** join/#bzflag hilmy (~hilmy@156.223.124.148)
09:45.22*** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001)
13:06.19blast007hmm.. so, modeltool now needs to link to curl because it uses TextUtils.  How should we be handling that?  We're only using TextUtils::tolower and TextUtils::tokenize in modeltool.  Should I make a new (simplified) TextUtils inside the modeltool directory?
14:43.09RoscoePColtranestatic library vs DLL?
14:43.24RoscoePColtraneoh... all one TextUtils.o
14:48.29RoscoePColtranewe can always just steal the url encoder from libcurl and put it into TextUtils... what we had was close, just wrong. There are correct implementations available on stackoverflow
14:49.00JeffMyes, copy the code
15:46.41*** join/#bzflag BZnotify (~BZnotify@192.30.252.45)
15:46.41BZnotify[13bzflag] 15JeffM2501 opened pull request #64: extend bz_ePlayerDieEventData to v2  (062.4...062.4_PlayerDieEventV2) 02https://git.io/vDUMW
15:46.41*** part/#bzflag BZnotify (~BZnotify@192.30.252.45)
16:03.07BulletCatcherIn the autotools build system we simply link modeltool with libcurl.
16:03.11BulletCatcherIf you don't want to do that in other build systems then here are four ways to make it work, in descending order of preference.
16:03.16BulletCatcher1. Move the url_??code functions from TextUtils to a different file (perhaps cURLManager).  This would acknowledge that we have requirements beyond "being a text utility" for grouping functions into a single file.
16:03.20BulletCatcher2. Rewrite TextUtils::url_??code to not use curl functions.  The disadvantage of this is that we would (re)take on the burden of maintaining that code.  It didn't work out so well for us in the past.
16:03.24BulletCatcher3. Move the four TextUtils functions used by modeltool (format, replace_all, tokenize, tolower) to a different file.  Same rationale as #1.
16:03.27BulletCatcher4. Copy the same to a different file, presumably in the tools/modeltool directory.  The disadvantage of this is that we must maintain two copies of the same source code, which is the most expensive form of code reuse.
16:35.17JeffM#3 seems easiest to me
16:36.13JeffMalso makes sense if modeltool is ever to be pushed into it's own or different repo
17:05.54*** join/#bzflag Void7 (uid197664@gateway/web/irccloud.com/x-atxreyrphqxuccdz)
17:25.29*** join/#bzflag BZnotify (~BZnotify@192.30.252.40)
17:25.29BZnotify[13bzflag] 15JeffM2501 opened pull request #65: Update Model tool and remove link to common (062.4...062.4_modelTool) 02https://git.io/vDUHn
17:25.29*** part/#bzflag BZnotify (~BZnotify@192.30.252.40)
17:25.52JeffMBulletCatcher: that should solve the immediate issue
17:32.16blast007I'm adding a SimpleTextUtils that just has the needed pieces
17:32.59blast007(and getting rid of common.h and the other external dependencies)
17:33.17JeffMthe project needs regex so it has to be changed to use the deps on windows
17:33.50blast007where does it use regex?
17:34.28JeffMdidn't check, the .sln had the old resex project in it so I assumed it needed it
17:34.37JeffMmaybe it doesn't need it anymore
17:34.52blast007it might have for the full TextUtils, but not the stripped down version
17:34.56blast007I'm build it without right now
17:34.58JeffMk
17:35.42blast007if we include headers in the header, do we also include them in the source file?  or just additional ones that the source file needs above and beyond?
17:36.09JeffMheaders should only be included once
17:36.13blast007k
17:36.21JeffMwhen possible
17:43.46blast007I'm also making the change you mentioned a while back where we can use '#define BZF_PLUGIN_CALL extern "C" __declspec( dllexport )' and then remove the .def files for the plugins.
17:44.12BulletCatcherHeader files (including BZFlag's) typically have a combination of #ifndef and #define at the top that makes it a noop if they are included multiple times.
17:44.15BulletCatcherWhen this is the case, it is merely a matter of style whether to include them in every file they are relevant or to rely upon nested includes.
17:44.16BulletCatcherDEVINFO doesn't address that question.
17:48.27JeffMyeah it won't be a problem, I think it's just cleaner to include them once, if you know that it's included elsewhere
17:49.29BulletCatcherSome developers will know what is included elsewhere and others won't, which is why there isn't a firm rule.
17:50.26JeffMdid you guys decide what to do about tools and various ancillary apps?
17:51.38BulletCatcherNo decision has been made, IIRC, which is effectively equivalent to the decision to leave them as-is.
17:54.54blast007BulletCatcher: I mean in the case with pairs of Thing.h and Thing.cxx.  Some headers that were included in the Thing.h where also in Thing.cxx, even though Thing.cxx includes Thing.h.
17:56.13BulletCatcherMy comments are intended to apply to a situation like that.
17:57.20blast007I was referring to "Some developers will know what is included elsewhere and others won't" with my last comment.  Since I'm talking about the obvious cases where it's matching header/source files.
17:58.41BulletCatcherWhat is obvious to you may not be obvious to others.
18:01.09*** join/#bzflag a_meteorite (~a_meteori@unaffiliated/ameteorite/x-000000001)
18:10.27*** join/#bzflag BZnotify (~BZnotify@192.30.252.41)
18:10.27BZnotify[13bzflag] 15JeffM2501 closed pull request #65: Update Model tool and remove link to common (062.4...062.4_modelTool) 02https://git.io/vDUHn
18:10.27*** part/#bzflag BZnotify (~BZnotify@192.30.252.41)
18:21.26*** join/#bzflag BZnotify (~BZnotify@192.30.252.42)
18:21.26BZnotify[13bzflag] 15blast007 pushed 2 new commits to 062.4: 02https://git.io/vDU5t
18:21.26BZnotify13bzflag/062.4 143a36517 15Scott Wichser: Update plugin solution/project files to Visual C++ 2015....
18:21.26BZnotify13bzflag/062.4 146c17b75 15Scott Wichser: Switch modeltool to a stripped down TextUtils called SimpleTextUtils so it doesn't have external dependencies.
18:21.26*** part/#bzflag BZnotify (~BZnotify@192.30.252.42)
18:22.58JeffMmodel tool belongs more with bzedit than anything
18:23.31blast007yeah, eventually it could just be built into whatever editor we focus on supporting
18:25.36*** join/#bzflag BZnotify (~BZnotify@192.30.252.40)
18:25.36BZnotify[13bzflag] 15blast007 closed pull request #64: extend bz_ePlayerDieEventData to v2  (062.4...062.4_PlayerDieEventV2) 02https://git.io/vDUMW
18:25.36*** part/#bzflag BZnotify (~BZnotify@192.30.252.40)
18:27.49JeffMI like the little "delete branch" button when a PR is closed
18:47.57blast007I've been seeing some warnings about "ignoring '/EDITANDCONTINUE' due to '/SAFESEH' specification".   The conficting options are C/C++ > General > Debug Information Format > Program Database for Edit and Continue, and Linker > Advanced > Image Has Safe Exception Handlers > Yes.
18:49.00JeffMI'd just turn off edit and continue
18:49.10blast007What should be the setting for 'Debug Information Format' for release and debug builds?  release and debug x64 (mostly) has it set to just 'Program Database'.  And the x64 stuff I looked at didn't have 'Image Has Safe Exception Handlers' set
18:49.12JeffMit never really works
18:49.33blast007should release have 'Program Database' as well?
18:49.45JeffMnon
18:49.46JeffMnone
18:49.49blast007k
18:49.53JeffMyou don't need debug info for release
18:50.07JeffMyou arnt' going to keep the PDBs for releases anyway
18:50.37JeffMthey give you the option to build PDBs for release, in case you ever want to be able to debug a customer's crash dump
18:50.44JeffMwe do that at work
19:00.11*** join/#bzflag BZnotify (~BZnotify@192.30.252.41)
19:00.11BZnotify[13bzflag] 15JMakey pushed 1 new commit to 062.4: 02https://git.io/vDUFk
19:00.11BZnotify13bzflag/062.4 14c4b5bf6 15Jeff Makey: Include math.h now that it isn't provided via common.h....
19:00.11*** part/#bzflag BZnotify (~BZnotify@192.30.252.41)
19:00.54BulletCatcherThat illustrates perfectly the challenge of choosing the best place(s) to include header files. :-)
19:07.50blast007that's more about differences in compilers :)
19:08.03blast007Visual C++ doesn't need math.h to build that
19:09.55BulletCatcherYup.  You make different choices depending on portability requirements.
19:20.06JeffMI think the std::math stuff is more
19:20.18JeffMCommon across platforms
19:24.28*** join/#bzflag BZnotify (~BZnotify@192.30.252.40)
19:24.29BZnotify[13bzflag-dependencies] 15blast007 pushed 1 new commit to 06master: 02https://git.io/vDUbm
19:24.29BZnotify13bzflag-dependencies/06master 14f7640de 15Scott Wichser: Update the regex solution/project to Visual C++ 2015 and remove the 2010 batch file.  Also fix up the Debug Information Format setting, preventing a warning.
19:24.29*** part/#bzflag BZnotify (~BZnotify@192.30.252.40)
19:54.12BulletCatchermath.h is POSIX.  Instead of that we could include cmath (the c++ header file), which appears to provide an overloaded sqrt() that calls the underlying sqrt(), sqrtf(), or sqrtl() as appropriate.
19:55.20BulletCatcherIt would be a significant effort to refactor our code to use the c++ API instead of POSIX, but it might give long-term benefits.
19:57.16BulletCatcherChanging character arrays to std::string would give us the near-term benefit of eliminating potential buffer overflows.
19:57.37*** join/#bzflag BZnotify (~BZnotify@192.30.252.34)
19:57.37BZnotify[13bzflag] 15blast007 closed pull request #49: Visual Studio 2015 (062.4...06vs) 02https://git.io/vwMzP
19:57.37*** part/#bzflag BZnotify (~BZnotify@192.30.252.34)
20:06.43JeffMthere is a ticket for using std::string already
20:07.27JeffMissue #4
20:12.33JeffMthat will not be an easy task,  Matching lines: 2692    Matching files: 392    Total files searched: 684
20:19.06JeffMthere are some uses of const char* you can't get away from, unless you want to break the API or get rid of windows as a server platofrm.
20:25.43*** join/#bzflag Zehra (~Kanone@unaffiliated/zehra)
20:50.09*** join/#bzflag BZnotify (~BZnotify@192.30.252.42)
20:50.09BZnotify[13bzflag] 15blast007 pushed 1 new commit to 062.4: 02https://git.io/vDUho
20:50.09BZnotify13bzflag/062.4 1416c8fe3 15Scott Wichser: Clean up Debug Information Format settings.  Treats warnings as errors for debug builds.  Ignore Winsock deprecated warnings in bzadmin.
20:50.09*** part/#bzflag BZnotify (~BZnotify@192.30.252.42)
20:59.43Notify03BZFlag:Zehra * 9344 /Getting_Help: improved content display
23:39.17*** join/#bzflag BZnotify (~BZnotify@192.30.252.40)
23:39.17BZnotify[13bzflag] 15JMakey pushed 1 new commit to 062.4: 02https://git.io/vDTLG
23:39.17BZnotify13bzflag/062.4 14a7f17f5 15Jeff Makey: Remove dependency on libCommon now that we have SimpleTextUtils.
23:39.17*** part/#bzflag BZnotify (~BZnotify@192.30.252.40)
23:48.11BulletCatcherNow that there are no external dependencies it would be easy to move modeltool out of the game tree and into its own branch or repo.
23:56.33JeffMwhat is the process for taking a section of code from one repo and putting it in another?

Generated by irclog2html.pl Modified by Tim Riker to work with infobot.