Dev meeting minutes 2011-09-19

Dev meeting minutes 2011-09-19

Minutes of the meetings between Spring developers are archived here.
Post Reply
Spring Developer
Posts: 1358
Joined: 16 Dec 2006, 20:59

Dev meeting minutes 2011-09-19

Post by zerver » 20 Sep 2011, 00:52

Present: <braindamage>, <hoijui>, <jk>, <kloot>, <tobi>, <zerver>

=== Introduce branch develop ===
<hoijui> Tobi has prepared the buildbot :-) thanks
<hoijui> so we could switch now
<hoijui> lets do it right now, during the meeting?
<hoijui> it is just a matter of us devs switching locally
<jk> yeah, already asked myself today, if I should commit to dev or master
<hoijui> yeah.. seems generally eveyrone used master still, as we said to give a clear change notice first
<jk> k
<zerver> so, anyone against switching now?
<jk> k so do a commit with notice to use dev branch from now on + description how to switch?
<kloot> switch after release, so we have an incentive
<hoijui> no, we should switch before the release
<hoijui> for once, because after the release really nobody should commti to master anymore
<hoijui> and second, to be able to test and setup stuff in advance
<kloot> it was a joke
<hoijui> and .. because there is no downside
<hoijui> k :D
<jk> >_<
<hoijui> was your commit thing also a joke, jK?
<zerver> The release must not be delayed by the switch :P
<hoijui> i dont think anything has to be changed in the repo for the switch
<hoijui> i just put develop HEAD to master HEAD
<hoijui> so they are at the same commit now
<hoijui> so if you do not have a local branch develop yet
<hoijui> you should be able to do:
<hoijui> git fetch
<hoijui> git checkout -b develop origin/develop
<jk> no, it wasn't
<hoijui> (if you are at origin master head
<hoijui> ok
<jk> esp. it was meant for abma & may be other regular 2nd level devs
<hoijui> we can make a comment for them
<jk> a commit is more obvious
<hoijui> if they dont use rss yes, but it makes little sense..
<hoijui> this is not soemthign in the history
<hoijui> but a decission taken at a point in time, independent of the repo content history
<hoijui> or a single brnach
<jk> and still many ppl fork us and may wonder why no commits were done anymore
<hoijui> and as we do it before the release, it is not too bad if someone fails to follow the rule
<hoijui> until the release
<hoijui> anyway, you cant do an empty commit
<jk> do a whitespace commit
<hoijui> if someone does not read RSS or comments but does read commti messages...
<hoijui> :P
<hoijui> thing is, that master will get updated to develop anyway
<jk> many ppl don't read forum
<hoijui> i mean a github comment
<jk> git hub comment are meant for commits & not general commit policy
<hoijui> who would read commit messages but not github comment, and would be stuck because of that?
<hoijui> it woudl only matter at release
<hoijui> where it will be announced anyway
<hoijui> Tobi, are you here?
<tobi> ya
<hoijui> please say something
<hoijui> regarding this matter
<hoijui> there simply is no mater.. nobody that follwos master closely will miss this
<hoijui> after two weeks or so (if the release has not happend by then) they would come ask
<zerver> I don't think it is an issue
<hoijui> if they missed all other clues
<hoijui> btw.. they get informed of the new branch, and see all commits there anyway
<tobi> yeah
<hoijui> whenever they fetch
<tobi> yup
<tobi> and the rss/frontpage of github shows that ppl push to spring/develop instead of spring/master, etc.
<jk> "whenever they fetch"?
<hoijui> btw, thw two comments i gave also work if you have local changes still, as you checkout an other branch, but to the same commit, which means git only changes the current branch reference
<jk> git pull doesn't inform me
<hoijui> the*
<hoijui> OMG
<hoijui> there is simply no issue
<hoijui> doh
<hoijui> i just realised..
<hoijui> omg == oh my god?
<hoijui> damn
<tobi> lol yeah
<hoijui> :D
<hoijui> i though of it as somethign different :D
<hoijui> just a sound
<hoijui> like duh
<zerver> there are variants such as OMFG
<zerver> and OMFGBBQ
<hoijui> :D
<hoijui> all start to look different now :D
<kloot> welcome to the internet?
<zerver> omfghax!!!
<hoijui> halleluya!
<jk> run "emerge wtf"
<jk> and then: "wtf omg"
<kloot> much like
<hoijui> :D
<tobi> so conclusion: no dummy commit, but just normal means of communications (forum)?
<hoijui> +1
<jk> hmm wtf doesn't know OMFG o_O
<zerver> speaking of hacks, I lolled reading gui_red_buildordermenu.lua the other day
<zerver> because it contains the word "hax" no less than 14 times
<tobi> high number of WTF/min
<jk> yeah, it sucks and it is the cause of many problems with BA
<zerver> yeah, reason I investigated it is that the UI was missing clicks
<hoijui> i guess they wil also use chilli some day for BA, and so it makes little sense to fix it?
<zerver> yea
<jk> first comes UHM fixes (to get release as soon as possible) then new addonhandler (needed for easy chili integration)
<hoijui> mmm
<hoijui> so.. can we switch to develop now?
<hoijui> i'll tell BD in chat and write PM to abma and koshi
<zerver> yeah
<tobi> possible open points (not blocking):
<tobi> - should develop be the "unnamed" branch in buildbot output?
<tobi> - I need to figure out how to change force builds through web to develop by default too, I found out later that they still do master
<hoijui> where would that name be, if it was not the unnamed one?
<tobi> I mean e.g. in installer filename
<tobi> develop is now like this: ... -gdfc87f6/
<tobi> while master is like this: ... -ge10dbf7/
<tobi> changing this is somewhat tougher because then stuff like the stacktrace translator needs to magically know whether an unnamed branch means develop or master (depending on build date?)
<hoijui> i woudl say master should stay unnamed
<tobi> +1
<hoijui> releases should not have "master" in the file names, s owe would have to manualyl rename them, and it can't hurt to have "develop" in non-release builds
<tobi> there are special cases anyway when building a tag, IIRC
<hoijui> mm :-)
<hoijui> ah yeah.. casue releases are tags yo umean, ok
<tobi> so what was the idea with version no. in develop?
<tobi> cause if we switch silently all develop versions will eternally be called 0.82.3.something
<hoijui> ... 24#p493324
<tobi> ah ty
<hoijui> hmm... yeah .. with this shceme, develop will have an irregular tag until the first minor release
<hoijui> as in.. it will have tag 0.83
<hoijui> and later on it will always have a + or -
<tobi> we can make a 0.83.0- tag in develop ofc
<hoijui> yeah
<hoijui> guess that makes sense, on the first commit after the release
<tobi> I wonder if I should still fix things that parse those version nums
<tobi> in any case I'll keep an eye open for breaking stuff
<hoijui> i always though of this beeing my duty so far..
<hoijui> ok, good :-)
<hoijui> but i gues you though about other stuff then i did..
<tobi> did you fix something already then?
<hoijui> i was thinking mostly engine stuff.. all thigns inside the repo
<hoijui> not really, now
<hoijui> no*
<hoijui> i changed some comments
<hoijui> in unitsync
<tobi> buildbot stuff is all in repo too
<hoijui> and i prepared cmake stuff to parse versions and read git describe and so on
<hoijui> mm ok
<hoijui> yeah i did not think about buildbot
<hoijui> i was alwyas lazy to test this stuff so far
<hoijui> and i was a bit unclear abotu some stuff
<hoijui> still am ...
<tobi> its hard to test because many of it is system integration stuff
<hoijui> mmm yeah
<tobi> and we don't really have a test buildbot and test github
<hoijui> and for my stuff (cmake and git related, with export to a C/C++ file, plain text and possibly others), it matters .. for example when to let cmake reconfigure automatically, or at all, and how
<hoijui> best is to just ignore that, which is what we also do now
<tobi> so for buildbot, should I still use the script?
<hoijui> i mean: when building locally, and having local changes since the lat commit, we do create all version info/strings as if it was exactly this commit
<hoijui> let me see..
<tobi> I see its building lots of develop stuff already.. good :)
<hoijui> :-)
<hoijui> where is that script?
<tobi> buildbot/slave/
<hoijui> ahh ok :-)
<hoijui> that will be done by cmake in the future
<tobi> ah, will, so isn't yet?
<hoijui> ah an other thing... if we do the whole version stuff through cmake, by reading from git-describe or a VERSION file (in case of a tarball), how would that be handled in VS or other systems?
<hoijui> yep, isnt yet done
<hoijui> so using this script is ok..
<hoijui> we can just empty it if it is not requried anymore
<hoijui> and remove the call to it form buildbot in a few years or so
<jk> imo even VS should use cmake
<tobi> just ignore those other systems for now
<hoijui> yeah that would be the optimum of course
<hoijui> ok
<tobi> VS using cmake would be cool but quite a lot of work AFAIK
<jk> cmake can generate VS projects
<tobi> yes, but all logic to find libs / set flags must have VS specific variant
<hoijui> can you give an example?
<tobi> me?
<jk> setting flags for VS doesn't make sense cause it won't sync
<hoijui> yeah.. i mean
<tobi> they don't want to debug?
<hoijui> cmake commands already abstract some stuff
<tobi> you need flags for much more than fixing sync
<hoijui> ah fllags.. yeah true
<hoijui> but for finding libs.. i would have though it should abstract that out
<jk> hmm those are gimmicks
<jk> (flags for other things than syncing)
<tobi> and in any case all gcc flags that we enable by default should be made conditional
<hoijui> zerver, you tried generating VS projects with cmake?
<hoijui> you mean, configurable through cmake?
<tobi> I think for libs it needs to look in ${project-root}/vclibs
<hoijui> i guess that cant hurt
<tobi> instead of /usr/lib etc.
<hoijui> yeah, but that is a simple change in a single place, from "mingwlibs/" to "vclibs/"
<tobi> kk
<hoijui> at least i think
<jk> that dir is already configurable via a cmake tag, or not?
<hoijui> yeah
<hoijui> so... everybody switched to develop already?
<tobi> me yes
<jk> hope so
<zerver> I did not try generating VS projects
<hoijui> me too
<kloot> any way to make github display the dev branch by default?
<tobi> ah, yes
<hoijui> ther is, but Tobi pointer out last time....
<hoijui> somethign, i forgot :D
<hoijui> ahh yeah
<hoijui> it woudl probably also mean that people will get rbanch develop as default
<hoijui> and one of the idea we had was, to use master as the default
<tobi> not so sure that becomes the default for git
<tobi> changed now, in any case
<hoijui> for cases where linux users have to compile spring release versions themselfs
<hoijui> ok :-)
<kloot> nice
<tobi> if you go to you see develop branch now
<hoijui> ahh yeah :-)
<hoijui> i do a test clone to see the default branch....
<tobi> k
<zerver> nice
<hoijui> default clone brnach is develop now
<tobi> ah ok, didn't expect that
<hoijui> i don't care too much
<hoijui> default checkout branch and what is shown by default on github is both not too important to me
<hoijui> would be nice if it coudl be different, but maybe also confusing
<hoijui> was not too much work so far to tell users to cheocut a tag after cloning
<hoijui> checkout*
<jk> hmm wiki tutorial needs update
<jk> will see tomorrow
<hoijui> forum PM sent to abma and koshi
<hoijui> next? :D
<tobi> brb

==> The develop branch is now up and running

=== How to test for 'must not compile' in UnitTests? ===
<jk> I need to test if code is illegal as wanted
<kloot> lol
<kloot> the only way to test if something does not compile... is by compiling it
<hoijui> hmm... i coudl imagine that would have to be done in somethign else
<hoijui> or say.. it would probably not be called unit test anymore
<jk> today I encoutered the new AI script with
<jk> can't I do something similar?
<hoijui> hmm.. or still call it that, but do it with cmake "trickery", not using boost
<hoijui> ah yeah
<jk> instead of running spring, it runs g++
<hoijui> that is also possible, though that can only be run on the buildbot
<hoijui> or say.. it is linux specific
<hoijui> ahh..
<hoijui> best woudl be, if it coudl be done wiht CTest i guess
<hoijui> that is what we use in CMake ...
<hoijui> i thnk :D
<tobi> should be possible to hack it into CMake isn't it?
<hoijui> yeah, pretty sure
<hoijui> would be a plus if CTest has something to support that already
<jk> ah so Boost UnitTests get run by CMake's CTest currently?
<hoijui> it is what we use
<hoijui> yes
<hoijui> The "ctest" executable is the CMake test driver program. CMake-generated build trees created for projects that use the ENABLE_TESTING and ADD_TEST commands have testing support. This program w
<tobi> cmake should be capable of this also as part of its ./configure `emulation' I think, just an idea in case CTest doesn't support this
<hoijui> ADD_TEST(NAME testCheckIsAbcCompiling COMMAND "${CMAKE_CXX_COMPILER}" "MyTestSource.cpp")
<hoijui> maybe somethign like that...
<hoijui> is hte best idea i could come up with
<jk> ah nvm
<jk> it is a op
<hoijui> path to the source will most likely have to be absolute
<tobi> + need to inverse the result
<hoijui> or you had to install the source or something... that is probably the ugly part
<hoijui> ahh yeah :D forgot that
<tobi> maybe if (you can make it to) run it as shell command you can simply run `! g++ -c myfailingfile.cpp'
<hoijui> guess it would have to be a wrapper script
<hoijui> i am not sure how ctest even works
<tobi> or that, wrapper script failgcc :)
<hoijui> if it looks at the commands return value, on stderr or if it intereact with boost testing in some special way (i think not)
<hoijui> mm :-)
<jk> ... ssionTests
<tobi> ah there you have it
<hoijui> hmm.. sounds good :-)
<hoijui> but i guess one had to include the boost macros
<hoijui> or copy and adapt them
<hoijui> i guess they dont come wiht cmake, but are somewehre in the boost repo
<hoijui> to be able to use commadns like boost_test_compile_fail
<jk> yeah, that what I am googling atm :)
<hoijui> ok :-)
<kloot> ... ting.cmake
<hoijui> nice :-)
<zerver> WILL_FAIL TRUE :P
<hoijui> :D
<hoijui> guess that is solved then..
<hoijui> tell me if you want me to do it, jk
<jk> thx, first trying it myself
<hoijui> ook :-)

==> jK will try to implement the 'failing' unit tests

=== Use if (unit) {} instead of if (unit != NULL) {} ? ===
<zerver> Yeah, I'm not sure I understand it
<hoijui> i ma wiht Tobi there
<hoijui> aehh..
<hoijui> i mean.. the green person :D
<kloot> it was I
<hoijui> ok :-)
<zerver> pointer = NULL is not confusing as I see it. pointer = 0 is a bit confusing though
<jk> I didn't said it confusing
<hoijui> it is about whetehre to use "if (unit) {}" or "if (unit != NULL) {}"
<jk> I said it is as: if (foo == true) {}
<zerver> Ah
<zerver> so you want (unit != NULL) always
<jk> no I want "if (unit) {}"
<hoijui> Kloot and me want that, jk wants the other thing
<zerver> :P
<hoijui> i take it, you do not care? :D
<zerver> I think I vote for (unit != NULL) in that case, because it is 100% clear
<jk> clear as if (foo == true) {} ...
<zerver> Why?
<jk> it is a redundant check
<kloot> you do not instantly see what foo is
<jk> neither for boolvars
<jk> and still you don't check them
<hoijui> with Kloots system, if a var is used alone in a booelan expression, you DO know that it is boolean
<zerver> if everyone uses (unit != NULL) then those checks that lack it can be assumed to be boolvars
<kloot> with the != NULL you know that when the != check is missing it must be boolean
<hoijui> hehe :D
<zerver> you were quicker :P
<hoijui> awesome
<zerver> but this means everyone must also use (int != 0) etc
<hoijui> yeah
<jk> you can never rely on that
<zerver> and please no assignment of "0" to pointers
<hoijui> that is not a contra argument
<jk> it is
<kloot> (technically I would like != 0x0 more for pointers, since null in c++ is this strange non-typesafe leftover)
<jk> any rule that is not always true is wrong
<hoijui> hehe
<jk> better use c++11 & NullPtr
<hoijui> do not use superior standard ever, cause its full potential only kicks in if it is used always
<hoijui> <- nope
<hoijui> is c++11 a realistic option?
<hoijui> for now
<jk> it is
<jk> most important stuff should work in gcc4.4 already
<hoijui> ok
<jk> ah NullPtr is 4.6 only :/
<hoijui> what about VS? :D
<hoijui> mmm
<zerver> Never seen any nullptrs
<jk> VS is very far, too
<hoijui> ok
<zerver> error C2065: 'nullptr' : undeclared identifier
<zerver> but the IDE colors it like a keyword
<hoijui> i guess it would, at best, work with latest VS only
<jk> you need to define a compileflag to enable c++0x/c++11
<hoijui> well anyway.. gcc 4.6 is not quite standard yet
<hoijui> so about the initla thing... i guess we will not settle for jk's suggestion?
<jk> static_assert, extern templates, auto types, strongly-typed enums are 4.4 already
<hoijui> define Kloots way as standard? or do not care?
<zerver> Not a very big deal I think. We 'recommend' use of Kloots way?
<hoijui> i am fine wiht that
<kloot> depends, if you want coding standards to be strict or recommended
<kloot> or strongly recommended ^^
<hoijui> hehe :D
<zerver> :)
<zerver> Spank those who fail to conform
<hoijui> luckily, in spring it is often quite clear anyway
<hoijui> like wiht the example of "unit"
<hoijui> it is pretty clear that it is not a boolean, due to its name
<hoijui> if it was unclear, i would like the != NULL to be used always, but i don't feel strong about this in general
<hoijui> i woudl rather get to beed soon ;-)
<kloot> I reserve the right to issue a damn good thrashing every time you do type &val
<zerver> :)
<hoijui> :D
<zerver> int a, &b, &c;
<hoijui> i hate these statements anyway
<hoijui> should be 3 lines
<jk> +0.7
<kloot> you can't do that with references
<hoijui> ah yeah :D
<zerver> int a, &b=X, &c=Y;
<zerver> whatever
<zerver> but you get the point
<hoijui> yeah.. so you need that ugly syntax to do be able to use even more ugly syntax
<hoijui> awwww i will have nightmares abotu this!
<jk> still it is a bordercase, you should define var where they get used, and not at the top of the function (that's the usage of such code)

==> We recommend if (pointer != NULL) {}, if (int != 0) {}, if (bool) {} etc.

=== Release ===
<zerver> So, will we release soon?
<hoijui> yes yes
<jk> need to fix UHM first
<zerver> lovely
<jk> but I give my best to fix them fast
<kloot> why dont you mantis the issues also?
<hoijui> yeah, just assing them toyourself, then nobody else will work on it, and it can be seen in the roadmap
<hoijui> can even be very simple
<zerver> If there are many issues, then you also have a chance of getting some help
<jk> cause I work on the code and already heavilly reorganized the code
<hoijui> we dont have to fully grapsh the problem in detail
<hoijui> grasp
<zerver> okay, nm then
<kloot> would have been better if you had fixed/reported the minor stuff before reorganizing
<jk> I encountered them afterwards

==> Release will be done after unsynced heightmap bugfixes are completed
0 x

Posts: 2434
Joined: 12 Oct 2007, 09:24

Re: Dev meeting minutes 2011-09-19

Post by Google_Frog » 20 Sep 2011, 09:01

Regarding UHM are there plans to fix the remaining gameplay mechanics issues that I have found?
  • Units refuse to fire through UHM
  • Radar view uses synced heightmap
  • Construction order allowance is checked against synced heightmap
Units refuse to fire through UHM
Given the implementation it is unreasonable for me to expect units to actually target with the UHM, this would require a reimplementation of the whole idea. Also targeting would be a kind of give-away.

If you shell an opponents base it will become covered in craters that you cannot see. If you order artillery to fire at a piece of terrain that is higher than reported by your UHM the artillery will refuse to fire, this could easily occur with an order to fire on the lip of a crater only a few elmos high. Artillery that 'randomly' (to an end user) does not fire is a bug with the game.

My suggestion to partially fix this is a weapon tag that causes a weapon to completely ignore terrain for the purpose of targeting. I don't think artillery with a hit radius of 500 elmos needs to care whether it's attack ground command underground by a few elmos.

Radar view uses synced heightmap
This is not particularly pressing but it's needed if anyone ever wants to make a game with deep intelligence warefare. But there are current engine issues that are more much gamebreaking for such an idea.

Construction order allowance is checked against synced heightmap
This provides an easy way to completely workaround the unsynced heightmap. I have already outlined how this could even be fixed modside in the mantis ticket so I don't see anything stopping an engine fix.
0 x

Spring Developer
Posts: 1864
Joined: 08 Oct 2006, 16:58

Re: Dev meeting minutes 2011-09-19

Post by Kloot » 20 Sep 2011, 12:58

Read please:
I myself wrote: Buildings can also only be placed on legal locations for the synced heightmap ==> on my list, but not until after 0.83

Radar view ==> ... non-trivial to make the visualization from an unsynced perspective ==> not on my list
0 x

Posts: 2434
Joined: 12 Oct 2007, 09:24

Re: Dev meeting minutes 2011-09-19

Post by Google_Frog » 20 Sep 2011, 13:08

<jk> need to fix UHM first
<zerver> lovely
<jk> but I give my best to fix them fast
I know what is on your list. If jk has started bugfixing he may want to know the missing features and think about fixing those too.
0 x

Post Reply

Return to “Meeting Minutes”