Separating/Modularizing the View

[hughperkins]

Hmmm, I get the same error. I'll look into it. It's easy to check, so I'll post back once that's sorted out

[hughperkins]

Right, so I went to the 'fork queue' to play around with that and see what happens, and got the following message:

Repo unavailable due to maintenanace
Repository under migration.

The route for your user could not be found. Usually this means that
your repositories are being migrated to a new storage server to
better serve you. Your repository should be available again very soon.

So, it seems simply: we just have to wait .

Edit: I tried cloning another of my repos, and it had the same result.

[Auswaschbar]

http://github.com/blog/505-state-of-the ... pace-day-1
They have moved to a new server. Give them some days to settle, or open a bugreport.

[hughperkins]

Yeah.

In the meantime, we can use patchfiles. Here is one that should in theory contain all the commits for headlessspring:

http://manageddreams.com/ailadder/downl ... ring.patch

(command used to create it: "git log --author=(myemailaddresshere) --stat -p >headlessspring.patch")

[imbaczek]

git format-patch is your friend. you could also use gitk to create a patch stack. apply patches with git apply to preserve commit info.

[hughperkins]

So that patchfile I uploaded wasn't useful?

Ok, so I did the following to create a new set of patches:

Code: Select all

git format-patch -o ../springheadless-patches -k a0534a809057dc2ba45c6c17e903de5384717fc4
grep hughperkins *
tar -cjf headlessspring_patchesfromformatpatch.tar.bz2 0229-First-added-to-repository.patch 0230-first-commited-to-headlessspring.patch 0231-missed-the-CMakeLists.txt-for-HeadlessSpring.patch 0232-headless-spring-corrected-build-bug-with-gml-includ.patch 0233-headlessstubs-added-sdl_joystick-functions.patch 0234-Headless-spring-obtains-filelist-from-rts-but-we-sw.patch 0235-added-readmes-into-headless-spring-directories.patch 

And the result is here:

http://manageddreams.com/ailadder/downl ... ch.tar.bz2

[hughperkins]

Ok, the git repo is accessible now:

git clone git://github.com/hughperkins/springheadless.git

[hughperkins]

As discussed in IRC, looking at forcing the config to low-graphics values.

What I'm doing at the moment is:
- in SpringApp, a new method "LoadFixedConfigs", which is called just before "UpdateOldConfigs"
- this method contains a #ifdef'd HEADLESS section that forces certain values:

(rest of posting truncated in preference to what is stated in the next post)

[hughperkins]

Ok, modified how this works after writing the last post.

Basically, in the previous version, it actually modified the global .springrc file.

In this new version, the overrides are only temporary.

In ConfigHandler:
- new methods SetOverride and SetStringOverride, and new map "dataoverrides"
- GetString checks dataoverrides first, then if it doesn't find a dataoverride, it looks in the config file values as normal

In SpringApp::LoadFixedConfigs(), this calls SetOverride to force the config values to the low-graphical/no-graphical settings for headless:

Code: Select all

/**
 * forces certain config values to certain values under certain
 * circumstances, eg for headless spring, we set all graphics parameters
 * to low
 */
void SpringApp::LoadFixedConfigs() {
#ifdef HEADLESS
   configHandler->SetOverride("AdvSky", 0 );
   configHandler->SetOverride("AdvUnitShading", 0 );
   // ... etc ...
#endif // HEADLESS
}

How does that sound?

[hughperkins]

Pushed to git://github.com/hughperkins/springheadless.git master.

Do you want to check it looks reasonable then push to spring master?

PS it seems that:
- in this version, sound is entirely disabled
- it loads quite a lot faster

[Auswaschbar]

Code: Select all

/**
 * forces certain config values to certain values under certain
 * circumstances, eg for headless spring, we set all graphics parameters
 * to low
 */
void SpringApp::LoadFixedConfigs() {
#ifdef HEADLESS
   configHandler->SetOverride("AdvSky", 0 );
   configHandler->SetOverride("AdvUnitShading", 0 );
   // ... etc ...
#endif // HEADLESS
}

How does that sound?

Stupid. If you want low values, then set it to low values. Thats what config files are for.

[hughperkins]

Stupid. If you want low values, then set it to low values. Thats what config files are for.

I'll leave that to you and hoijui to decide. Either way is fine by me...

In defence of overriding the config file, there are two issues:
- headless spring will not work when certain config values are set
- providing the user with the capability to configure graphical options in headless spring would seem to add little value to the user when graphical output is entirely disabled

[hoijui]

As building springheadless needs more packages installed then running it, the usual course of action might be to compile it on a normal system, and copy it over to the headless machine (this is what i did).
We could make a CMake target called springheadless-prepare or the like, which copies everything that is needed to a separate directory. in this step, we would also copy a preassembled config file to this directory, setting all graphical and sound settings off or to a minimum.
That ok?

i tried compiling on windows, and it fails when configuring:

Code: Select all

CMake Error in tools/HeadlessSpring/CMakeLists.txt:
  Cannot find source file "icon.o".  Tried extensions .c .C .c++ .cc .cpp
  .cxx .m .M .mm .h .hh .h++ .hm .hpp .hxx .in .txx

i tried to fix it with this, and cleaning cache + reconfigure (rts/CMakeLists.txt):

Code: Select all

-	LIST(APPEND sysfiles icon.o)
+	LIST(APPEND sysfiles ${CMAKE_CURRENT_BINARY_DIR}/icon.o)

to no avail. any ideas?
any ideas?

[imbaczek]

icon.o should be a product of icon.rc compilation, check there.

[hoijui]

yeah, that is exxaclty where i looked, and changed this line.
it looks like this compilation/cmake-command is only executed when the output is the input of an other command. this is the case for spring.exe and for spring-headless.exe, so it shoudl work in my eyes ...
maybe the problem occures cause it is specified in the same CMakeLists.txt for spring.exe, but an other one for spring-headless.exe?
will try to make a macro out of it or something...

[hoijui]

got around to fix the problem with icon.o and two other things.
now it looks like the headlessstubs need quite some adjustment for windows.
someone who can compile spring on a windows machine would have to fix it (hugh does not have that). the errors i got so far were in glewstub.c, looks like some types are different in windows.
so i guess its checking them in hte headers and ifdeffing work.

[hughperkins]

Yeah, and I can't grab a virtualbox image off someone, since that would need a license... really nice not to have to think about licensing stuff any more, I mean on Ubuntu. Hmm, getting off topic :-DDD

Some changes to git, hoijui perhaps you can check that these are not too insane?:

- I branched the old 'master' branch to 'oldmaster2009oct31', just in case I've done something I shouldn't have
- then I force pushed a new master, that has all our changes right at the end. don't ask how I managed that but it looks quite cool right?
- and the main point of the exercise is: branch 'changes_against_0_80_5_1' should in theory contains the changes against 0.80.5.1 version of spring, which I intend to build on Ubuntu and upload

What I did to get 0.80.5.1. First, got master to have all our changes at the end, which wasn't intentional, but simply by doing:

- git checkout master
- git fetch spring
- git rebase spring/master

... we achieve that goal!!!!

For some reason, our changes were now all at the end! Which is sweet I think? If it is correct?

Next, to create 'changes_against_0_80_5_1':
- I opened gitk master, and found the commit-ish of the commit just *before* my first commit, which was 64b2ef07ab77b 'KAIK: prevent build-up of huge swarms of idle aircraft' (basically, the last commit from spring/master at this time)
- I found the commit-ish of our last commit, which was 1562e54bf507 'print to infolog that we are a headless build'
- and we already have the 0.80.5.1 tag from spring

then:
- git checkout -b changes_against_0_80_5_1
- git rebase --onto 0.80.5.1 <commit just before my first changes> <our last commit>. In other words;
- git rebase --onto 0.80.5.1 64b2ef07ab77b 1562e54bf507

What this does, is it basically cherry-picks every commit from just after 64b2ef07ab77b right up to and including 1562e54bf507, and adds them as children of 0.80.5.1 , and replaces our current branch with the result. I think.

then (after checking a bit in gitk):
- git checkout -b oldmaster2009oct31 origin/master
- git push origin oldmaster2009oct31
- git push origin changes_against_0_80_5_1
- git push origin master -f

[hughperkins]

Slight update to master branch and to changesagainst_0_80_5_1:
- liblobby added to required libraries

A build against 0.80.5.1, on Ubuntu Jaunty is at:

http://manageddreams.com/ailadder/downl ... ty.tar.bz2

[hoijui]

you should only force push (to a collaborative repo) if it is really, really needed; basically if you did something badly wrong.
for one thing, it causes confusion and extra work to the others in the team, as they have to force fetch/pull in turn. it also changes the history of things, eg all the SHA1 IDs of all our commits are now different.
you should only merge branches, not rebase one on the other.
i did the same in the past though, and they told me not to do it

if i am right, the 0.80.5.1 tag was added after the last commit of master i merged back into springheadless, so all you would have had to do was this (having springheadless/master checked-out):
git merge springOrigin/0.80.5-branch
or
git merge 0.80.5.1
(the branch contains additional fixes which should be sync-safe)

[hughperkins]

you should only merge branches, not rebase one on the other.

Ok, fair enough. I will change my heuristic from:
- always rebase, unless you are merging from a branch you've been working on onto master

to:
- always merge, except from origin/master to master, which should be a rebase

Is that roughly how you do it?

I guess another heuristic could be:
- always rebase, unless you are merging from a branch you've been working on onto master, or: it would imply needing a force push