=== Welcome ===
<[ARP]hoijui_g5> all here
<[ARP]hoijui_g5> somehow
<zerver> the absent minded pack
=== replace some static libs with shared ones? (for example md5, 7z) ===
<[ARP]hoijui_g5> http://springrts.com/phpbb/viewtopic.php?f=12&t=24813
<zerver> yeah, we better get started or im gonna go repair my percolator
<[ARP]hoijui_g5> whats that?
<zerver> coffe machine
<[ARP]hoijui_g5> ahh
<[ARP]hoijui_g5> so yeah.. on topic
<zerver> static libs are always better, less files and dependencies
<[ARP]hoijui_g5> the question is, whether we could remove eg 7z lib sources (static lib) and depend on the dyn-lib
<[ARP]hoijui_g5> ?
<zerver> or thats my opinion...
<[ARP]hoijui_g5> The question is more... if we need the sources patched, or if we need always the same version of the lib/src
<[ARP]hoijui_g5> if not, then we should use the dyn lib
<[ARP]hoijui_g5> it means our source base is smaller, less to compile, less to maintain
<[LCC]jK> 7z can be made dynamic
<[ARP]hoijui_g5> bascially, moving the responsibility from us to the distro maintainers
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> md5?
<Kloot> an md5 lib should not change often
<Kloot> so probably safe to rely on the distro
<Kloot> 7z updates more regularly afaik
<[LCC]jK> still 7z isn't synced
<[ARP]hoijui_g5> yeah.. that is the important thing
<[ARP]hoijui_g5> synced
<[LCC]jK> so it shouldn't matter, if they change stuff
<[ARP]hoijui_g5> and patches
<[ARP]hoijui_g5> the only candidates in my eyes are 7z, md5 and minizip
<[LCC]jK> yup, only lua & streflop need to be static
<Kloot> 7z is still synced in the sense that extraction must produce bit-for-bit identical files for all archives regardless of version, but that is probably guaranteed
<[ARP]hoijui_g5> oscpack is very small, and does not exist as dyn lib on any distro
<[ARP]hoijui_g5> i think so, yeah
<[ARP]hoijui_g5> the crc is also generated by 7z i think, but that has to be the same one different versions/platforms too
<[ARP]hoijui_g5> in their specs
<[LCC]jK> do we even use the crc from the zips?
<[ARP]hoijui_g5> same for md5 and minizip
<[ARP]hoijui_g5> i think yes
<[ARP]hoijui_g5> just saw it a week ago.. already not sure anymore :D
<[ARP]hoijui_g5> will check...
<[ARP]hoijui_g5> yes we do
<[LCC]jK> :)
<[ARP]hoijui_g5> with both zip and 7z
<[ARP]hoijui_g5> ok so.. these 3 gonna be made dynamic then
Conclusions:
Some source files will be ripped out from the repo and replaced with libs
=== C++ unit testing ===
<[ARP]hoijui_g5> more stuff on the meeting etherpad
<[ARP]hoijui_g5> has anyone of you ever used unit tests in C++?
<[ARP]hoijui_g5> me not
<[ARP]hoijui_g5> not even in java really, but i know that it is more common there
<[LCC]jK> I don't even know how they should help us
<[ARP]hoijui_g5> i woudl like to setup up the basic framework
<[ARP]hoijui_g5> then.. for new stuff, or when bored for old one, we can add them if we want
<[ARP]hoijui_g5> you never used them?
<[LCC]jK> no
<[LCC]jK> didn't even heard of those
<[ARP]hoijui_g5> you can test simple stuff like.. utility functions
<[ARP]hoijui_g5> ah ok
<zerver> me neither
<[ARP]hoijui_g5> most basic unit tests look like this:
<Kloot> unit tests are most useful for code where you know what the result should be
<[ARP]hoijui_g5> yeah
<[LCC]jK> from what I read they should check the interfaces (e.g. checking if streflop always gives the same results)
<Kloot> ie. math functions
<[ARP]hoijui_g5> yeah
<[ARP]hoijui_g5> these tests are most easy to write, cheap to execute, and therefore what you will see most often
<Kloot> dunno how you could write unittesting code for the pathfinder say when the engine keeps changing
<[LCC]jK> but you still need to write those tests yourself, so how do such apps help you to do such things faster than custom ones?
<[ARP]hoijui_g5> yeah that would be very complex.
<[ARP]hoijui_g5> they dont
<[ARP]hoijui_g5> what they do is..
<[ARP]hoijui_g5> they provide itnerfaces to execute the tests, to present the outcomes .. in html for example
<[ARP]hoijui_g5> to alarm devs if a test fails
<[ARP]hoijui_g5> there are also toosl that show you which parts of your code are well covered with tests
<[ARP]hoijui_g5> buildbot frameworks may have support for integrating them
<[ARP]hoijui_g5> in java, this is all very standardised
<[LCC]jK> hmmm so the big work still has developer by writting those tests ...
<[ARP]hoijui_g5> yes
<[LCC]jK> not very helpfull apps ...
<[LCC]jK> -l
<[ARP]hoijui_g5> :D
<zerver> it does not seem like friday night entertainment to me
<[ARP]hoijui_g5> well.. it is kind of obvious that you can nto generate these tests automatically
<[RoX]Tobi> unit testing is a technique, not an app, in any case :)
<[LCC]jK> still they use c++ syntax which isn't ... code saving
<[ARP]hoijui_g5> yeah true
<[ARP]hoijui_g5> it is proven that it saves you time, after time
<[ARP]hoijui_g5> also.. this discussion shoudl not be about if we should write unit tests for everything
<[ARP]hoijui_g5> nobody is forced to do that
<[ARP]hoijui_g5> but we shoudl agree on a framework, so if someone wants to write unit tests, he can add them
<[LCC]jK> I wonder what could be tested with those
<[RoX]Tobi> problem with spring is that much of it is legacy code (i.e. not easily testable aka badly designed)
<[ARP]hoijui_g5> and we can slowly build up support for it
<[ARP]hoijui_g5> yeah true
<[ARP]hoijui_g5> ugly code is harder to test
<zerver> possible in theory maybe to apply to spring maybe, but who is gonna do it
<[ARP]hoijui_g5> all utility functions, eg in fuilesystem can be tested
<[ARP]hoijui_g5> as said zerver, that is not the question here
<[RoX]Tobi> https://github.com/tvo/spring/commits/u ... loshandler
<[RoX]Tobi> thats something I did quite a while ago in that direction but didn't really finish it (as in, integrate into master and/or actually write tests)
<[ARP]hoijui_g5> ah :D
<[ARP]hoijui_g5> so.. you wrote your own system?
<[RoX]Tobi> IOW it's just some refactoring until the LosHandler is testable, and then I plumped in some unit testing framework
<[RoX]Tobi> let me check which one
<[RoX]Tobi> ah the boost one
<[LCC]jK> LOS, RayTracing & pathfinder could profit by such tests
<[ARP]hoijui_g5> mm ok
<[LCC]jK> but still, the discussion doesn't make sense if no one plans to write UnitTests in the next 3months
<[ARP]hoijui_g5> i woudl likely write some for file-system
<[RoX]Tobi> it does make sense if someone is willing to set up the infra and make some (example) tests
<[ARP]hoijui_g5> yeah
<[RoX]Tobi> as imo a major reason for not unittesting anything is that now you need to first set up the whole infra
<[ARP]hoijui_g5> yeah
<[ARP]hoijui_g5> have you done unit testin in C++ before this try, Tobi?
<[RoX]Tobi> no
<[ARP]hoijui_g5> ok
<[RoX]Tobi> Spring is a few orders of magnitude larger than any other C++ codebase I've touched probably anyway (except for a few months of KDE hacking a loooong time ago)
<[ARP]hoijui_g5> as i suggested boost or cpptest, and tobi used boost, i guess that is prime candidate now
<[ARP]hoijui_g5> :D
<[ARP]hoijui_g5> mm k
<[ARP]hoijui_g5> i know from java:
<[ARP]hoijui_g5> you have the sources and the test sources in different dirs, in maven structure for example:
<[ARP]hoijui_g5> src/main/java/
<[ARP]hoijui_g5> src/test/java/
<[ARP]hoijui_g5> in these dirs, you use identical package structures
<[ARP]hoijui_g5> and usualyl you have one class in the test structure per class in the real source
<[ARP]hoijui_g5> src/main/java/mypackage/Util.java
<[ARP]hoijui_g5> src/test/java/mypackage/UtilTest.java
<[LCC]jK> yeah, I would prefer to have them in a diff folder, else they clutter a lot
<[ARP]hoijui_g5> mm
<[LCC]jK> also I don't think we need to keep the same directory structure in the tests dir, because we would never test all classes
<[LCC]jK> I assume there is need for 4-10 tests
<[ARP]hoijui_g5> hmm... i woudl preffer the same structure
<[ARP]hoijui_g5> it does not really hurt
<[ARP]hoijui_g5> in java, they even test GUIs automatically.. for well structured code, you can unit-test nearly everything
<[LCC]jK> it would cause many empty dirs and it is hard to maintain if things change in the rts/ dir
<[ARP]hoijui_g5> often you even get nicer structured code, if you write it to be unit-testable
<[ARP]hoijui_g5> ah.. no empty dirs
<[LCC]jK> even a dir with just dirs is empty
<[ARP]hoijui_g5> you jsut create the dir when you place the first thest there
<[ARP]hoijui_g5> test*
<[ARP]hoijui_g5> when i write a test for FileSystem.h, i create the same relative path
<[ARP]hoijui_g5> before that, the FileSystem/ dir wont exist in the test structure
<[LCC]jK> still you would create an empty system dir
<[LCC]jK> just for its subdir FileSystem
<[ARP]hoijui_g5> yeah..
<[ARP]hoijui_g5> i cant see how this is unclean though
<[RoX]Tobi> I think that is easier than later having to move stuff around when you want to add a test for something in System
<[ARP]hoijui_g5> yeah
<[LCC]jK> I would prefer to add tests/testXYZ for each test
<[LCC]jK> e.g. tests/FileSystem, tests/LOS, tests/RayTracing
<[ARP]hoijui_g5> mmm is not good
<[ARP]hoijui_g5> .. i have worked on many projects with unit tests
<[ARP]hoijui_g5> all of them use the same structure
<[ARP]hoijui_g5> it is just no contra there
<[ARP]hoijui_g5> why would a dir without plain files be unclean?
<[ARP]hoijui_g5> our tools/ dir for example
<[LCC]jK> because when you move dirs in the rts-dir you would have to reorder the same things in the tests-dir
<[ARP]hoijui_g5> had only dirs until recently
<[ARP]hoijui_g5> yeah
<[ARP]hoijui_g5> that is no big deal
<[LCC]jK> it's an extra (non-obvious) step to maintain
<[ARP]hoijui_g5> in the worst case, you can still do that later
<[ARP]hoijui_g5> if you forget it
<[ARP]hoijui_g5> it also happens very seldomly that we move dirs under rts
<[ARP]hoijui_g5> if you do it once, you have to remember, or someone else will notice
<[LCC]jK> but we move files into other dirs from time to time
<[ARP]hoijui_g5> no problem really
<Kloot> the amount of work wrt directory management is probably 0.00001% of getting critical parts of Spring in a unit-testable state in the first place
<[ARP]hoijui_g5> yeah
<[ARP]hoijui_g5> also.. we may get like 10 test classes in the next 2 years at best
<[ARP]hoijui_g5> maybe just trust everyone else who uses this technique.. considering you jsut heard of it today
<[ARP]hoijui_g5> or tobi and me, who know it some
<[ARP]hoijui_g5> so... should we settle for boost (in case anyone wants to start this)?
<[LCC]jK> or what ever the first one prefers >_<
<[LCC]jK> but boost seems lighweight
<[LCC]jK> compared to cpptest
<[ARP]hoijui_g5> mmm
<[ARP]hoijui_g5> ok lets say boost then, and if the first one uses somethign else which is not totally off, thats ok to
<[ARP]hoijui_g5> next?
<[RoX]Tobi> just pick one and try imo, c++ unit testing stuff is all very messy imo (no clear best framework that everyone uses etc.)
<[ARP]hoijui_g5> mmm appeard like that to me too
<[ARP]hoijui_g5> with C, it seems to be worse even. many more frameworks
<[RoX]Tobi> not in the least because c++ kinda sucks for unit testing because it's unmanaged (so one failing test can crash your whole test framework unless you run each test in separate process)
<[ARP]hoijui_g5> mmm
<[RoX]Tobi> (still applies if you leave out `for unit testing'
)<[ARP]hoijui_g5> :D
<[ARP]hoijui_g5> was thinking the same :D
<Kloot> java unittest the c++ unittests
<[ARP]hoijui_g5> we shoudl just change language
<[ARP]hoijui_g5> hehe :D
<[ARP]hoijui_g5> yeah.. sadly.. i dont think it woudl be best fo both worlds :D
<[RoX]Tobi> would just mean the tested code can crash the whole JVM
<[ARP]hoijui_g5> yeah. and you still cant use reflection, which is one of the core things that make it nicer in java
Conclusions:
Unit testing is not prohibited, if anyone likes to do it, go ahead
=== git rules ===
<[ARP]hoijui_g5> we already have a git guidelines etherpad
<[LCC]jK> very important is this one: "separate unrelated changes into separate commits"
<[LCC]jK> >_<
<[ARP]hoijui_g5> yeah
<[LCC]jK> we should agree on those guidelines
<[ARP]hoijui_g5> +1
<Kloot> here comes the inquisition :]
<[ARP]hoijui_g5> Kloot is violating them most often
<[ARP]hoijui_g5> yeah.. actually we just want to be mean to you Kloot
<Kloot> I noticed
<[ARP]hoijui_g5> especially me of course
<[ARP]hoijui_g5> it has no rationale behind it
<[ARP]hoijui_g5> you are such a poor boy!
<Kloot> spare the sarcasm bitte
<zerver> separating the changes might be more work than the changes themselves
<[ARP]hoijui_g5> you started that shit again
<Kloot> and you are making really big mountains out of molehills
<[LCC]jK> separating them are jsut few clicks in git-gui
<[ARP]hoijui_g5> thing is this: the way you do it, it is easier for you
<Kloot> I follow regulations to the point that it is still fun to work on this project
<[ARP]hoijui_g5> the guidelines are better for everyone else except the committer
<zerver> it is easy to forget to commit in git gui, and sometimes changes are loosely connected
<[ARP]hoijui_g5> adn evne for the commiter it is better, later on
<[LCC]jK> also Kloot, even merged changes from different files
<[ARP]hoijui_g5> if you make changes to intervoven that it takes more time to separate them then the changes themselfs, you did it totally wrong in the first place
<[ARP]hoijui_g5> just do not change formatting in this case
<[ARP]hoijui_g5> plus i gave instructions and offered help for how to separate easily
<[LCC]jK> you can even merge multiple formatting changes in one commit, but then it should really only contain formatting changes
<zerver> i say that too strict rules takes the fun out of programming
<zerver> you must remember this is volunteers we are talking about
<[LCC]jK> and it makes the live of the other devs much easier
<[ARP]hoijui_g5> it also keeps the fun in for eveyrone else though
<[ARP]hoijui_g5> its a 1 or many decission
<[ARP]hoijui_g5> jk and me follow these rules.. you dont have to tell you what it takes
<[ARP]hoijui_g5> i find it totally acceptable
<Kloot> is this really a project-critical matter to you, or just something you find annoying?
<[LCC]jK> it is the big advantage of git-gui that you can split commits with changes in the same file
<[ARP]hoijui_g5> well... the to things you did this week, which jk commented on
<[LCC]jK> it is really project critical, because I stopped deep-checking many of your commits
<[ARP]hoijui_g5> where you introduced bugs silently..
<zerver> i try to follow the rules too, but im not going to spend 10 minutes hand picking chunks in git gui if i forget to commit
<[ARP]hoijui_g5> that is more then just a bit annoying
<[LCC]jK> it just takes too much time to check them
<Kloot> you know there can be bugs introduced in format-only commits as well
<[ARP]hoijui_g5> yeah
<zerver> hand picking chunks is a risky business too, you might do it wrong
<Kloot> and when you spam those it's just as painful to find them
<[LCC]jK> but they will be more obvious between only formatting changes
<[ARP]hoijui_g5> zerver, genrerally you shoudl not have to do it!
<[ARP]hoijui_g5> you just dont do formatting changes when editing a file
<[ARP]hoijui_g5> if you see formatting problems, you do them after you committed
<[ARP]hoijui_g5> if you cant handle the separating
<[ARP]hoijui_g5> i have a simple script that lets me separate stuff with my favourite GUI diff editor, if it has to be
<[ARP]hoijui_g5> it is no big thing
<[ARP]hoijui_g5> it just shows lack of respect for other devs and anyone else who might be looking at commits
<[ARP]hoijui_g5> if you only care for what is least work for your own
<Kloot> it's using one's judgment to follow the spirit of the rules instead of the letter
<[ARP]hoijui_g5> egoistic judgment
<Kloot> but if this such a principal issue for you, I'll stop
<Kloot> no, I get the sense you are highly personally annoyed and so am I
<[ARP]hoijui_g5> i am annoyed by your egoism causing others more work, yes
<[LCC]jK> I am not annoyed, I am frustrated by the extra work given by others
<Kloot> like checking each of your formatting commits causes more work for me?
<[LCC]jK> you know that each line in those formatting commits needs to do 1:1 the same as before
<[RoX]Tobi> TBH I have to agree with hoijui as I've experienced how epically much longer it takes to make a bugfix release branch by cherry-picking from master when there is no one-to-one match between commits and changes
<Kloot> [LCC]jK, yes, and where there are 1000s in a row...
<[ARP]hoijui_g5> mm that is a reason too
<Kloot> in practice 1:1 match does not last so long anyway when larger changes to the code are made in master
<[ARP]hoijui_g5> when i did some changes in the past you did not like (rightfully so) and told me, and explained, i stopped doing these
<[ARP]hoijui_g5> eg const_cast stuff
<[RoX]Tobi> the 1:1 match will last, it is simply conceptual; there is no need for the commits to keep applying cleanly on master
<[ARP]hoijui_g5> yeah that
<Kloot> eh, you mean on the release branch?
<Kloot> (it's master that starts to diverge)
<[ARP]hoijui_g5> i also did not know that you check all my formatting commits
<[RoX]Tobi> it is only to make it easy to skim through commits and know quickly which ones are easier/harder / more/less important to process
<[RoX]Tobi> (process for any purpose, whether it be cherry picking or reviewing or simply keeping up to date with what others are doing)
<Kloot> [ARP]hoijui_g5: I check each and every commit usually
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> well.. the idea of the formatting commits is to not have to check them
<[ARP]hoijui_g5> but if you do... yeah...
<[ARP]hoijui_g5> :/
<[ARP]hoijui_g5> so what now..
<Kloot> I know, but iirc atr least two bugs were introduced in such commits, that's why I started skimming those too
<[ARP]hoijui_g5> should we vote on the policy(ies)?
<[ARP]hoijui_g5> yeah true that
<Kloot> so for me, the total number of LOC-to-check is the same
<Kloot> and I thought others did too
<[ARP]hoijui_g5> yeah if you check them, that defeats this pro of course, but there are still the others
<[RoX]Tobi> personally I never check(ed) formatting commits
<zerver> I never checked any commits
<zerver> and I'm happy
<[ARP]hoijui_g5> :D
<zerver> we may need a new addition to git rules
<[ARP]hoijui_g5> sure
<zerver> if someone makes s bugfix or similar, and you dislike the way it is done, dont revert, instead improve the commit
<[ARP]hoijui_g5> improve only makes sense if it needs marginal changes only
<[ARP]hoijui_g5> if you want it totally different, revert is better
<[ARP]hoijui_g5> why woudl you not want revert?
<zerver> because revert --> no bugfix at all
<Kloot> that means when someone commits a hackish fix and no-one feels like cleaniing it up/restructuring it the hack stays
<zerver> this SlowUpdate thing we talked about is a prime example
<zerver> what im saying is, try to improve it, and you will see how easy it is
<zerver> it may not be as easy as you think to write a cleaner solution
<Kloot> yeah I know
<Kloot> but those hacks accumulate
<[ARP]hoijui_g5> yeah
<Kloot> and eventually nothing is easy to clean anymore
<Kloot> spring is already tangled up too much (you change something in part A and code in seemingly unrelated part B breaks)
<Kloot> (good case to catch with unittests)
<zerver> yeah
<zerver> im just saying i didnt find a better way than SlowUpdate yet, so the bug remains
<zerver> and i don't think that is better than a semi-hackish way
<Kloot> how serious is the bug compared to the level of "entropy" the solution introduces?
<[ARP]hoijui_g5> what? .. i explaiend a way to you in github comments
<[ARP]hoijui_g5> you said you though of it yourself already
<zerver> it didnt work out, the code produced was spaghetti
<zerver> too much of the code in slowupdate need to be executed in this case i guess, so break out is a no go
<zerver> ie, i could break it out, but would end up with something that is almost a copy of SlowUpdate
<[ARP]hoijui_g5> even if it is the qhole of slow update, it woudl be better then what you had
<[ARP]hoijui_g5> whole*
<[ARP]hoijui_g5> conceptually clean
<[ARP]hoijui_g5> -er
<zerver> mmmkay
<zerver> i will do that then
<[ARP]hoijui_g5> so... for git rules... what is the outcome now?
<[ARP]hoijui_g5> hmm maybe we herewith define them as strict rules, not as sort of recommendations?
<zerver> how many days on bread and water if violated?
<Kloot> and you still need to check commits all the time for violations
<[ARP]hoijui_g5> so.. you do not want to follow that rule (splitting)?
<Kloot> I'll respect the majority vote, but just know strict regulations don't work when people are not payed/under contract
<[ARP]hoijui_g5> mmm
<zerver> BTW Kloot, I very much agree with you that too strict regulations don't work in volunteer projects like this one
<zerver> (if you want a boss yelling at you, go and get a paid job instead)
<[RoX]Tobi> it's a matter of mutual benefit.. it's a small investment which can save others way more time, allowing them to be more productive, which is good for the project as a whole
<zerver> indeed, and im not saying break the rules on purpose, but shit happens
<zerver> i much rather have 3 good bugfixes in one commit than no bugfix at all
<[RoX]Tobi> yeah, no need to punish ppl for that or so, but it's good to bring it up so that everyone can improve
<[ARP]hoijui_g5> you dont accidentially put 3 bug fixes into one commit
<zerver> u can, but that would be rare
<[RoX]Tobi> (IMO that is actually one of the reasonsn to skim / review commits)
<[ARP]hoijui_g5> saying it happens accidentially... really.. that is just lieing
<[ARP]hoijui_g5> its like having accidential sex
<zerver>
<zerver> not they way I see it
<zerver> you start fixing bug 1, then by chance discover the somewhat related bug 2...
<abma_irc> nobody here is perfect...
<zerver> or even more likelly, when fixing bug 1, you come across some ugly code
<zerver> and your fingers are twitching, eager to fix it
<[ARP]hoijui_g5> we all know how it happens, there is still nothing accidential there
<[ARP]hoijui_g5> if you want, i can explain again what i do to separate stuff afterwards
<[ARP]hoijui_g5> i have a script called gfilter
<[ARP]hoijui_g5> i call it on a file, and it then opens the two versions of the file in meld (my fav diff editor)
<[ARP]hoijui_g5> the one with all current changes, and the unchanged one
<[ARP]hoijui_g5> then you just do a few clicks (usually, the bug fix parts is small)
<[ARP]hoijui_g5> then save
<[ARP]hoijui_g5> and commit wiht git gui
<[ARP]hoijui_g5> if the separation is hard, becuase both changesets are large, you should not have started to mix them in the first place, or live with it taking a bit longer to separate
<[RoX]Tobi> in git gui you can also right click -> stage hunk / stage line as long as they are at least a little bit separated
<zerver> I wish my fingers were twitching to do any of those procedures
<[ARP]hoijui_g5> DOH! i did not know Tobi :D
<zerver> i have occasinally staged chunks though
<[ARP]hoijui_g5> yeah.. in most cases that should be sufficient.. much easier :D
<[RoX]Tobi> it's the number one reason I prefer git gui to git add / git commit on commandline (most ppl I've spoken to about git prefer commandline :))
<[ARP]hoijui_g5> mmm
<[RoX]Tobi> but I haven't yet been able to make sense of this interactive add mode (git add -i or -p IIRC)
<[ARP]hoijui_g5> ahh never heard of that
<[ARP]hoijui_g5> it lets you choose only part of files to stage?
<zerver> i still not figured out what command sequence in git gui that equals "git pull"
<zerver> i read its fetch & merge, but git gui is complicated
<Kloot> pull is shorthand for fetch+merge yes
<zerver> so exactly what menu items in git gui would i chose?
<[ARP]hoijui_g5> i only use it for committing
<[RoX]Tobi> personally I use commandline for clone/pull and branching/merging/complex stuff and use git gui for staging, committing and pushing
<zerver> same here
<zerver> makes me think that git gui can be improved
<[ARP]hoijui_g5> yeah, stageing and committing here
<[ARP]hoijui_g5> they should do something about the windows eol problem
<[RoX]Tobi> that's biggest problem yeah
<[ARP]hoijui_g5> after that, i guess GUI tool support would imprive muhc faster
<[ARP]hoijui_g5> as that is mainly something that windows users want
<[ARP]hoijui_g5> i would also not want to work on that if the base tool had suhc a major flaw
Conclusions:
Split commits are preferred and Git Gui could be better
=== name-value pair properties for objects (eg in unit, feature, weaponDef)? ===
<[ARP]hoijui_g5> ok then that next topic...
<[ARP]hoijui_g5> it is something that came to me in half delirium.. is probably totally unrealizable in C++
<[ARP]hoijui_g5> the idea:
<[ARP]hoijui_g5> as we have these objects (feature, unit, weapon) and the properties exist in different .. ways
<[ARP]hoijui_g5> like.. some in the class Unit as members
<[ARP]hoijui_g5> there is also a properties map in some classes
<[ARP]hoijui_g5> some are in struct unitDef as member
<[ARP]hoijui_g5> some exist only in lua
<[ARP]hoijui_g5> and i wondered if there is a way to unify them
<[ARP]hoijui_g5> most simple idea:
<[ARP]hoijui_g5> .. is alreayd quite ugly and complex :D
<[ARP]hoijui_g5> the actual values are stored in arrays (one per each basic type: float, int, bool,...)
<zerver> should work, unless access is performance critical
<[LCC]jK> there was already such a discussion with saving all those things in a std::map
<[ARP]hoijui_g5> yeah.. if performance is no problem, it is easier
<[LCC]jK> but it was dismissed because it is too performance critical code
<[ARP]hoijui_g5> i though of it liek this:
<[ARP]hoijui_g5> properties have a name(string), but you never access them directly with that, but through an index
<[ARP]hoijui_g5> you can request the index for a property
<[LCC]jK> and then you need to buffer those ids -> just clutters the whole code
<[ARP]hoijui_g5> then.. eg store that index in a static var or something
<[ARP]hoijui_g5> yeah
<[ARP]hoijui_g5> it owuld be ugly... i guess it would work relatively nice in languages like ruby
<abma_irc> re :)
<[ARP]hoijui_g5> lets just forget it :D
<[ARP]hoijui_g5> hey abma!
Conclusions:
Object properties stored in any non O(1) data structure would be too slow
=== plan for big refactors (regarding branches - how to not messup them) ===
<[ARP]hoijui_g5> so.. when we start doign big refactors
<[ARP]hoijui_g5> what would we do to not "loose" branches
<[ARP]hoijui_g5> whether our own or those of others
<[ARP]hoijui_g5> maybe just... announce when these things happen, and maybe skim through github to see who has branches
<[ARP]hoijui_g5> and tell them to merge master in frequently during the next month or something
<[LCC]jK> what is so critical?
<[ARP]hoijui_g5> mm... what do you mean?
<[ARP]hoijui_g5> i mean...
<[ARP]hoijui_g5> when there is lots of heavy changes comming up
<[ARP]hoijui_g5> adn people see like 200 files wiht conflicts when trying to merge, they often give it up totally
<[ARP]hoijui_g5> even some spring devs seem to fear merge conflicts, so no wonder
<[ARP]hoijui_g5> it sounds really bad if you have not yet seen t often
<[LCC]jK> you want to make "master" for releases only, and add a new branch "develop", or what do you mean?
<[ARP]hoijui_g5> and.. when they would merge often, that problem would seem.. smaller
<[ARP]hoijui_g5> i want to do that yes, but that is unrelated to this topic
<[ARP]hoijui_g5> i just mean... as we plan to restructure stuff
<[ARP]hoijui_g5> or maybe .. as a general rule.. we should maybe ... tell people to merge more often
<[ARP]hoijui_g5> or inform them of upcomming changes.. and ask if they want their branches merged in before that
<[ARP]hoijui_g5> maybe announce on github
<[ARP]hoijui_g5> in a way so everyone who has a fork of spring and uses RSS feed sees it
<[ARP]hoijui_g5> mmm nothign really to discuss i guess
<zerver> i have no objections
<[ARP]hoijui_g5> :D
<[ARP]hoijui_g5> ok
<[RoX]Tobi> I think it is fine if refactorer use common sense and take quick look on github, forums and/or etherpad to check whether there are any branches with major changes in the area he wants to refactor
<[ARP]hoijui_g5> hmm.. yeah also an option
<[ARP]hoijui_g5> more.. minimal
<[RoX]Tobi> and brancher takes has his own responsibility to merge often
<[ARP]hoijui_g5> optimized
<[ARP]hoijui_g5> yeah true
<[RoX]Tobi> I think there's no need to formalize this, just be pragmatic and go ahead
<[ARP]hoijui_g5> maybe just tell them once, as a general rule
<[ARP]hoijui_g5> i remember that one of you told me to merge master in from time to time, when working on my ai interface branch (still svn back then)
<[ARP]hoijui_g5> i did not even think on that
<[ARP]hoijui_g5> yeah ok.. maybe i will make a forum post or on github, maybe not.. nothing more to be done
<[ARP]hoijui_g5> that was last thing on the list
<[ARP]hoijui_g5> anyone has somethign else?
<Kloot> when is 82.7 planned?
<[ARP]hoijui_g5> i need koshi to repack rapid first
<[ARP]hoijui_g5> and... as it is now in the release branch, the build stance stuff is worse then before
<abma_irc> hm, whats wrong there?
<Kloot> with the std::max() removed?
<[ARP]hoijui_g5> what happens not too unfrequently (muhc mroe often then the builder frozen problem, for me):
<zerver> it has gotten worse?
<[ARP]hoijui_g5> con is told to build a structure, but has to move away to be able ot build it
<[ARP]hoijui_g5> it moves, stops, but is still in the way
<[ARP]hoijui_g5> then tries to build anyway, and fails, and the build order is discarged
<zerver> yeah, that is old bug or issue
<[ARP]hoijui_g5> its something else, but it is worse in my eyes
<zerver> not related to the buildstance/ slowupdate thing
<[ARP]hoijui_g5> mmm ok.. felt like it happens more often.. but yeah.. my felign is not worth much
<[ARP]hoijui_g5> ok
<[ARP]hoijui_g5> some more test games on release branch woudl be nice
<[ARP]hoijui_g5> i had quite some with AI, and godde did his pathing tests with earlier versions
<Kloot> only godde did any serious pathing tests though (and I already knew about most of the issues he reported)
<Kloot> you basically can't get volunteers for largescale tests
<[LCC]jK> Licho said ZKLobby is ready for multi-engine version support
<[LCC]jK> will ask him if it really is
<[LCC]jK> *multi-version engine support
Conclusions:
Please be careful and inform other devs when making big changes in master
