Date: 19-3-2012
Present: Tobi, zerver, jK, abma


add pr-downloader as submodule?
<jK>gentoo already has an ebuild for it
<abma>aaah, didn't know that
<abma>its not really needed as submodule. but it would be much easier to distribute...
<abma>but it seems like lobbies would love to use it (when the interface for the lib is finished)
<jK>make it a submodule then
<abma>also i would use it on the buildslave for downloading the games / maps
<Tobi>poke me if you need me for something, got too much stuff to do atm to participate much
<abma>ok, thanks.. i will do that after the release
<abma>(if nobody complains in the minutes)

conclusion: will be added after next release if nobody complains here


enable openmp as default?
<abma>i saw its already done
<abma>it seems to be only disabled on the buildslaves because of cmake caching
<jK>yup tested it and it was static linked
<abma>[LCC]jK: is that ok?
<jK>buildbot might missing the opengl suppport in gcc
<jK>erm openmp
<abma>ok...
<jK>for now it's okay
<abma>ok, then after release clean cache
<jK>can be solved later
<jK>but i found another issue
<abma>yeah
<zerver>regarding OpenMP, did you do some profiling to verify that it actually gives a speedup?
<jK>btw I even trying to compile cross compile devil (the distributed one was compiled with msvc), but it seems it's not that easy ...
<jK>+am
<jK>zerver, yes
<zerver>ok
<jK>still spring threads would profit a lot by `a smart cpu affinity algo`
<jK>windows AND linux thread schedulers just suck
<jK>e.g. if you got one thread with 100% cpu usage on linux, the kernel will move it across all threads (so each core has ~50% usage)
<jK>biggest problem with this is the core will run on lowest frequency cause it is less than ~75%
<zerver>you mean and i7 with boost etc
<jK>even w/o boost
<zerver>I did not know it need so high load to enable the turbo boost
<jK>now I mean the default cpu freq. scaling
<zerver>speedstep
<jK>steps 800MHz, 2.1GHz, 2.5GHz, 3.2GHz here
<zerver>Yeah, an option to lock the Sim thread in MT to a specific core would be good
<jK>that helps in most cases yes
<jK>but to really solve it, it needs a smart scheduler. A `tool` (=thread in spring) that checks all spring threads, and if it eats more than a specific amount of %, it sets the affinity in such a way that the threads don't block each other
<jK>also it should set affinity of all omp threads even w/o such a % limit
<jK>@previous topic: also I got this on my todo list for a long time http://msdn.microsoft.com/en-us/library/ms684247.aspx (but it seems the file dependencies are only included in minw64 and not 32bit so adding support for it needs some cmake magic)

conclusion: is enabled as default now, so debian/ubuntu/self-compiles will use it from now on, for the buildslaves (win32 + macosx) its enabled after next release


current devil in installer depends on msvcp80.dll but only msvcp71.dll is included
<abma>thats bad
<abma>can msvcp80.dll easily be added?
<jK>I already saw that in the release threads that some ppl had to install vc++ runtime packages
<abma>aaaah, doh
<abma>didn't see that yet
<jK>but now I found out the cause
<jK>problem is ...
<jK>the way we included msvcp71.dll is ... illegal
<jK>m$ has strict rules for doing so
<abma>oops
<jK>either we put _all_ files in a subdir
<jK>or we run their .exe installer
<abma>so, remove it and add the vc++ runtime?
<abma> / installer
<jK>duno how to change the installer to run a .exe
<abma>i can do that...
<abma>thats command "Exec"
<abma>just point me to the correct vc++ runtime...
<jK>http://msdn.microsoft.com/en-us/library/ms235299(v=vs.80).aspx
<jK>http://msdn.microsoft.com/en-us/library/ms235624(v=vs.80).aspx
<jK>those are the documents "how to include vc++ runtime in your project"
<jK>this is the installer package: http://www.microsoft.com/download/en/de ... en&id=5638
<abma>ok, thx
<abma>ok, vcredist is added to the installer / msvcr*dll removed from mingwlibs
<abma>hopefully it works :-D
<abma>i tested with wine... but
<jK>will test in virtualbox once it finished
<jK>by somehow such things run uber slow in my vbox :-/
<jK>mingw takes 30-60mins to check changed files etc.
<abma>build finished
<abma>i start my vm, too
<jK>i extracted vcredist_x86.exe to spring installdir
<jK>but didn't run it
<jK>are you sure about the args?
<jK>there is a quote error for sure
<jK>ExecWait '"${VCREDIST}" /q:a /c:"msiexec /i vcredist.msi /qn'
<jK>-> /c:"msiexec
<jK>that quote isn't closed
<jK>the "/c:" argument seems to not work at all
<jK>only `vcredist_x86.exe /q:a` runs fine
<jK>k fixed
<abma>[LCC]jK: uhm.. no...
<abma>sorry, didn't see that
<abma>only the the last " was missing
<abma>but if /q:a works fine...
<jK>it needed an uppercase C
<jK>also the command was slightly different
<jK>http://blogs.msdn.com/b/astebner/archive/2006/08/23/715755.aspx
<jK>->Note about standalone VC++ redistributable packages
<jK>crap didn't worked
<jK>k then "/q:a" only
<abma>[LCC]jK: i would expect, that its a bit shorter...
<abma>${VCREDIST} is the same as VCREDI~3.EXE i guess
<abma>i think it was only the missing escape char
<abma>does /q:a show a dialog box?
<jK>yup
<abma>ExecWait '"${VCREDIST}" /q:a /c:"msiexec /i vcredist.msi /qn"' should be fine imo
<abma>i try here again
<abma>locally with hopefully fixed installer
<abma>in wine its bad to test
<jK>${VCREDIST} is the same as VCREDI~3.EXE i guess -> tru but the VCREDI~3.EXE cmd is run in a different folder
<jK>-> /C:"echo foo" is execute in the unpacked dir of ${VCREDIST}
<jK>which contains again an .exe
<jK>that needs to be run again to finally get the .msi
<abma>ouch
<abma>who did such crap? :-D
<jK>unpack with winrar to see it yourself
<jK>never the less the cmd didn't worked when run from cmake, possibly a quote issue
<jK>never saw cmdline args using ""foo""
<jK>double-double-quotes
<abma>then i prefer /q:a, even if it showas a dialog
<abma>VCREDI~... maybe doesn't work in all cases
<jK>yep
<jK>crap
<jK>still doesn't execute it
<jK>so it tries to run it from wrong dir
<abma>ah, lol
<abma> /q is quiet without dialog
<abma>yeah, $INSTDIR is missing
<abma>i fix that
<abma>damn, it was a long time ago i wrote nsis stuff :-/
<abma>meh, 3 errors in two lines or so :-D
<jK>my record was 6 bugfix commits or so
<jK>*typofix
<abma>lets see if i can break that record :-D
<abma>hmm, i hope its fixed now...
<abma>i test tomorrow on a win7 machine
<abma>so its hopefully fine
<abma>it ignores return codes, so if the vcredist fails it still continues
<abma>hmm, skip the other points in favor of making a release?
<abma>also, most of them make only sense after the release + a few days "testing"


conclusion: msvcp71.dll removed from mingwlibs and vcredist_x86.exe was added to the win32 installer. so, please test the installer before the next release is set live on the lobby server.



Codenames for releases
<abma>thoughts?
<abma>if we do, i would like some endangered plans/animals or so...
<jK>@codenames, releases got a subtitle for a year already, that + message text is already enough work
<abma>hm, yeah i know :-/
<jK>*since
<abma>a release is still (to) many work
<jK>paying attention to endangered species or honoring ppl/ideas in history with codenames is a nice idea but too much work
<abma>yeah, thats my opinion, too
<abma>for that we would need some marketing guy

conclusion: no codenames yet (marketing guy needed who is willing to do the work...)



Note: i rearranged text a bit

So what effect is this going to have on portable installs?

Why doesn't spring just separate stuff out like every other program does, IE bin/libs/etc

vcredist_x86.exe is currently installed, when the engine is installed, regardless if its portable or non portable install. How/what should the installer do? Imo cleanest would be, to not run it on portable installs. If its still neded, it can be run by the user as vcredist_x86.exe is extracted to the installation dir, too.

What/How to seperate? The vcredist_x86.exe seems to be a requirement, without it, unitsync / other stuff doesn't work.


(and yep, i/we didn't think about the portable installation when we added this, thanks for this hint)

Hmm is there really no way to make it work without installing stuff? ZKL expects portable to be a real portable -> unzip and go.
Players get ZKL only and this then downloads/unzips engine as needed.

Is there no way to make it work with libs in the zip?

in portable mode, vcredist_x86.exe isn't installed. see https://github.com/spring/spring/commit ... 70a8f46440 (implemented a few minutes ago)

Well I'mma just add the contents of vcredist to portable. Microshaft can go screw themselves, if they can find it.

Or can I just include a file that was needed or something? I could care less about M$. How can I provide the same thing I have been?

Microsoft has codenames. Everytime i read Dreamspark, i die a little inside.