Dev meeting minutes Monday, 4. July 2011

Dev meeting minutes Monday, 4. July 2011

Minutes of the meetings between Spring developers are archived here.
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Dev meeting minutes Monday, 4. July 2011

Post by hoijui »

Date: Monday, 4. July 2011
Present: BrainDamage, hoijui, abma, zerver, jK, Kloot, Tobi


_Agenda____________________________________________________
  • New logging frontend
  • Release plan
  • Release Candidate
  • Gamasutra interview
  • New config system (& compiling with LTO)
  • Deprecate AllowStartPosition callin?
  • C++ philosophical stuff, too deep for you!

_Main_conclusions____________________________________________

conclusions:
  • we will be using a new logging frontend: ILog.h (http://pastebin.com/C937qyr4)
  • unsigned BAAAD! signed... gooooood!
  • BrainDamage will work on SpringLobby to support multiple spring versions
  • release is not imminent
  • the new config system by Tobi is pretty much ready, and it comes well equipped ;-)
  • abma will replace the engine supplied minimap widget with a start-pos-marker widget (default off) (DONE)
  • sein(ed)!!!



_The_meeting________________________________________________

>> Tobi joined!
>> abma joined!
>> hoijui joined!
>> jK joined!

New logging frontend
<hoijui> I am writing a new logging frontend
<hoijui> http://pastebin.com/C937qyr4
<hoijui> code using it looks like this:
<hoijui> http://sl.pastebin.com/9PDRQ7DG
<hoijui> the thing with sections (== log sub-systems) is not optimal yet
<hoijui> but i am quite happy with the rest
>> zerver joined![/b]
<hoijui> i have come to the conclusion that there is no good logging frontend API for C++
<hoijui> they all suck in many ways
<hoijui> all of them have too many deps and are complex
<hoijui> Boost.Log is badly supported on mingw, and has lots of features qw do not need, whihc make it complex (liek arbitrary attributes)
<hoijui> pantheios is meant to be leightweight, but despite beeing only a frontend, it depends on two libs, and has no CMake build files (plus the only/main dev is unreachable since like 4 months already)
<hoijui> eveyrthign else is at least as bad
<hoijui> and this approach still allows us to use them as backend later, without polluting all files with their deps
<hoijui> zerver:
<hoijui> hoijui http://pastebin.com/C937qyr4
<hoijui> hoijui code using it looks like this:
<hoijui> hoijui http://sl.pastebin.com/9PDRQ7DG
<hoijui> I am writing a new logging frontend
<zerver> k
<Tobi> is it practical to have no ordering between log levels?
<Tobi> oh nm
<Tobi> why the characters too ?
<hoijui> the characters are shorter, and all the smae length
<hoijui> if you want to keep final log entries small
<Tobi> oh you use that for printing
<hoijui> yep
<hoijui> only there
<Tobi> bit harder to grep for though unless you have a good unique prefix/suffix for them and/or you can anchor the grep to start of line
<hoijui> http://pastebin.com/isbZVtp0
<hoijui> a sample sink, logging only to console
<hoijui> yeah...
<hoijui> they could be used like in xorg log files for example
<hoijui> or like in this sink, where they are always the first char of line
<hoijui> in xorg, they do it like
<hoijui> (EE) error message here
<hoijui> (WW) warning message
<Tobi> ah yeah something like that may work
<Tobi> wouldn't it be better to keep this level->char mapping in the implementation?
<hoijui> yeah .. i was not sure which woudl be better
<Tobi> could also reduce log_isLevelEnabled from a number of if statements to a simple comparison
<hoijui> i guess yes
<hoijui> i first though i coudl keep log levels out of implementation compleetly, but that is not possible anyway
<hoijui> as is seen in this simple sink already
<Tobi> assuming that it doesn't make sense to e.g. only display warnings, but not fatal errors
<hoijui> mm.. what does this have to do wiht the level-> char mapping?
<hoijui> but yeah.. i will move that mapping to the sink
<hoijui> also the string one
<Tobi> if isLevelEnabled gets a level it can just do return (messageLevel >= wantedLevel);
<hoijui> yeah
<Tobi> if it gets a char it needs a reverse mapping or a switch / if-else chain
<hoijui> yeah.. but it alreayd gets the level as number
<hoijui> unsigned char
<hoijui> i just though we would not need more then 255 levels anyway
<Tobi> make it int anyway, char suggests to many it is a character :)
<Tobi> and compiler will put 4 bytes on the stack in any case
<hoijui> aww common :D
<hoijui> really?
<Tobi> yes
<hoijui> cant it combine 4 chars into 32 bit?
<Tobi> hmm don't know, checking calling convention
<hoijui> this function is used for frontend <-> sink communication only
<hoijui> the user of the frontend should never use it
<Tobi> doesn't influence my opinion that integral arguments should just be int whenever possible, and not be `optimized' for their envisioned max range
<Tobi> you noticed how I thought the character was being passed to the function and not the log level because it was declared as unsigned char instead of int ;-)
<hoijui> yeah :D
<hoijui> i also hate that in C/C++
<hoijui> in java there is byte and char
<hoijui> we could use a uint8
<Tobi> but why?
<Tobi> what's wrong with `int' ? :)
<hoijui> it is too big
<hoijui> more then 255 levels woudl be bad even
<Tobi> it can only store 4,2 x 10^9 values
<hoijui> more then 10 is already bad
>> Kloot joined!
<Tobi> no one forces you to use them all
<hoijui> to me, there is no reason to use int here
<hoijui> hey Kloot
<Kloot> lo
<jK> char neither saves memory nor cpu usage
<Tobi> as I see it, the reason is, that int / bool / float are kind of the basic primitive concepts, and things like short int, long int, even unsigned int are implementation details you should *only* care about when it absolutely necessary
<Tobi> i.e. if you need to load 4 billion of them so every bit saved counts
<hoijui> well ok
<hoijui> ill change it then
<Tobi> cool :P
<hoijui> i still think it is stupid, but i'll just add a comemnt that it coudl be unsinged char (in cas someone would reuse it elsewhere)
<hoijui> case*
<hoijui> anything else?
<Tobi> another reason is that although it kind of indicates the range it is not type safe at all
<Tobi> since afaik the compiler will silently let you pass in an int and have it be truncated at runtime
<Tobi> no, rest seems cool
<hoijui> what if i have a 64bit integer, bassed to an function taking a 32bit integer?
<Tobi> only lack of streams is a bit :( but it would be easy to put that as layer on top of it in case it is required (even though I don't like the stream output stuff it's practical e.g. in templates)
<hoijui> i deliberatly do nto want streams
<hoijui> as written in the header comment
<hoijui> as it makes later internationalization harder
<Tobi> hmm actually it kind of sucks to also not be able to pass std::strings though
<hoijui> the main log message should be one string
<Tobi> don't think you can do that safely through varargs
<hoijui> yeah, i also think it is not possible
<Tobi> that might hurt adoption :/
<hoijui> you mean as main message or as parameters?
<hoijui> i mean.. varargs, not parameters
<Tobi> varargs yeah
<Tobi> means everyone will need to put .c_str() after their strings on the calling sites
<hoijui> it is not possible now either, for printf style logging lines, and streams woud have to be changed anyway
<Tobi> indeed, it's not possible at all (except maybe with insane amount of templating, is this maybe what boost::format does ?)
<hoijui> yeah true.. with that it is possible
<hoijui> they use a special operator % for passing the varargs
<hoijui> instead of adding them with ,
<Tobi> hmm yeah that possible
<Tobi> but that is completely different thing from what you want to achieve I guess
<hoijui> yeah
<hoijui> i wnat it simple
<hoijui> if you really need something like boost format
<hoijui> you can use boost format
<Tobi> well I fear that I will just use a std::ostringstream to build the message and pass that in the cases where I have lots of non-PODs I want to output
<hoijui> yeah, use that of boost format
<hoijui> or*
<Tobi> it kind of defeats the purpose for spring though if that results in duplication of patterns like those
<hoijui> as said, i think streams are bad for logging
<Tobi> any reasons apart from i18n?
<hoijui> simplicity, C compatibility
<jK> current logsystem has already a std::ostringstream syntax
<hoijui> yep
<Tobi> yes, and I like it, even though I'm traditionally a fan of printf-style formatting
<jK> I prefer printf too (because the final string is separated in space from the arguments)
<hoijui> i dont see the huge ammounts of messages as you describe them
<hoijui> wiht many nonPOD varargs
<jK> while with std::ostringstream you have to do some brainwork to get the final result
<Tobi> yeah
>> BrainDamage joined!
<Tobi> hoijui: ok, well maybe it is good enough for big parts of spring then
<hoijui> :-)
<hoijui> i already use it for tests, and converted the System/Net part locally
<Tobi> I just know that e.g. in my config branch I actually used stream based things and it was good, cause I didn't need to think on stuff like adding .c_str() everywhere
<hoijui> seems to work well in practise, and makes decoupling really easy
<hoijui> mmm
<Tobi> actually stream based is a bad term, I'd prefer something more readable AND more typesafe :P
<hoijui> well.. we have compiler warnigns for that... we are very close ot no warnings by now, so you should usually see it (if not, i would ;-) )
<Tobi> yeah true
<hoijui> hey BrainDamage!
<hoijui> next?
<Tobi> yeah, ok, I'll see how it works out
<BrainDamage> hiho
<hoijui> for special cases, you could still add something like IAdvancedLog.h with stream support and stuff
<Tobi> yes
<Tobi> type safe might be required for a macro like TRACE_SYNC too
<hoijui> mmm

conclusions:
  • hoijui will do the adjustments discussed to ILog.h (http://pastebin.com/C937qyr4):
    • convert level unsigned char -> int
    • move two utility functions from frontend to sink

    and then put it into master
  • unsigned BAAAD! signed... gooooood!



Release plan
<hoijui> dont think there is much to say here..
<hoijui> it is all going along ok i guess..
<zerver> yep
<hoijui> BrainDamage.. you said you may look into multi-version support in a week or so?
<hoijui> for SL
<BrainDamage> yes, it's actually already present in internal logic since years, i'd have to add hooks for lobby protocol & gui to allow chosing multiple engines
<hoijui> ahh :-)
<hoijui> good good
<hoijui> i guess i will tell Licho and Satirik to also get together wiht aegis then
<hoijui> next?

conclusions:
  • BrainDamage will work on SpringLobby to support multiple spring versions
  • release is not imminent



Release Candidate
<hoijui> dont think it makes sense right now
<zerver> too much bugware ?
<hoijui> especially as we kind of have to switch to the new branching model too, when we do that
<hoijui> yeah that is the primary reason
<abma> yep, some new crashes introduced
<jK> oh is Assimp still used for obj parsing?
<hoijui> this does not contain everything i think
<Kloot> <jK>: no
<jK> k - Assimp is still missing a lot code
<hoijui> so ti is practically non-functional?
<hoijui> or just buggy?
<jK> it is functional in its limits
<hoijui> mmm ok
<jK> no explode-pices etc.
<jK> *pieces
<hoijui> ah.. it misses all the adjustments Kloot made to his obj loader? like inverting normals bla stuff, and rotation fixes and such
<hoijui> ah
<jK> yeah, the config format is missing a lot too
<hoijui> i see..

conclusions:
  • (again) release is not imminent



Gamasutra interview
<hoijui> is the text ready?
<Kloot> the parts I wrote are, dunno if others have things to add still
<jK> headwords are, currently write them down in text
<jK> *writing
<hoijui> i have the feeling that it will be way too sophisticated and long anyway :D
<hoijui> the response i got for my answers was something like:
<hoijui> "some very interesting answers, looks like i can quote some of it"
<Tobi> I looked through it today and it seemed fine
<hoijui> so.. he might just pick out a few small things he likes
<Tobi> didn't really have anything to add at that moment
<hoijui> ok then.. when jk is done, send (after meeting)
<hoijui> ?
<Kloot> +1
<abma> +1
<Tobi> ok
<jK> k

conclusions:
  • answers to interview questions from Gamasutra will be sent and the end of the meeting



New config system (features/config-rework) (& compiling with LTO)
<hoijui> it is finnished?
<hoijui> ready for merge in?
<Tobi> not completely
<Tobi> but opinions are welcome
<Tobi> sec, will paste a link
<hoijui> all descriptions for all config values added? :D
<hoijui> ok
<Tobi> no and I won't take that upon me :P
<hoijui> :D
<hoijui> i did it for commands too!
<Tobi> I already converted 50 config values from int to bool, cause it were bools :P
<hoijui> ;-)
<hoijui> mmm that is nice!
<hoijui> i always hated that
<hoijui> also*
<Tobi> https://github.com/spring/spring/compar ... fig-rework
<Tobi> in particular I now even made a kind of internal DSL for specifying config meta data
<Tobi> best example up to now is here : https://github.com/spring/spring/compar ... rk#diff-87
<Tobi> other random features:
<Tobi> - no storing of default values anymoe
<Tobi> - multiple overriding config sources possible (could be used to make e.g. a template that overrides default in certain cases)
<Tobi> - automagic clamping if minimum/maximum value have been specified
<hoijui> mmm :-)
<Tobi> - all (or at least most) instances of an integer config var now converted to bool
<Tobi> *that were used as a bool
<Tobi> so less of this stupid !! conversion operators :)
<hoijui> :D
<hoijui> nice
<Tobi> and I'm looking to get rid of a bunch of std::max / std::min around config var fetches and replace them with minimum/maximum values
<hoijui> will ther also be somethign new for unitsync, to fetch list of config values plus descriptions or soemthing?
<hoijui> mmm
<Tobi> that could be a future thing but I don't intend to add that in the branch
<hoijui> ok :-)
<Tobi> also in the branch spring can be reflect on its own config variables, so its easy to make e.g. an option to dump all config vars + their defaults / minimums/maximums / description to file
<Tobi> -be
<hoijui> mmm :-)
<abma> very nice... easier docs :)
<Tobi> and I made it somewhat preserve comments in the config file, although this is still a little big buggy
<Tobi> (adds some empty lines where they are not expected)
<jK> nice
<hoijui> when in a source file, i want to use or define a config value
<hoijui> how muhc will i have to include (including recursive includes)
<hoijui> or say.. i am thinking of tests again now
<Tobi> one file more than before I think, ConfigVariable.h, which is now included by ConfigHandler.h
<hoijui> ok
<hoijui> and source wise?
<hoijui> how many .cpps
<hoijui> ahh ill check myself..
<Tobi> 6
<Tobi> System/Config/*
<Tobi> + config depends on logOutput obviously
<hoijui> hehe :D
<Tobi> and the locator depends on Platform/Misc
<hoijui> github does not like the / in your branch name either
<hoijui> https://github.com/spring/spring/branch ... fig-rework
<jK> why "obviously"?
<jK> you mean in the cpp, not the header, or?
<Tobi> because many things require log output
<Tobi> yeah in the cpp
<hoijui> ok
<Tobi> although I think it is just for the few lines where it says which sources it uses
<hoijui> wel the logoutput is not a problem
<hoijui> all tests will use logging anyway
<jK> btw anyone tried LTO with GCC4.6 yet?
<hoijui> it will be ILog,h afterwards
<hoijui> i will have to think about it...
<Tobi> maybe the worst thing is that it drags in <sstream> (it already did so though)
<hoijui> would it be possible to use a stup implementation
<Tobi> maybe I could factor that out with external template instantiations, but I don't know how well that is supported on different compilers atm
<hoijui> is sstream large?
<Tobi> no clue
<hoijui> i care more for our own sources
<Tobi> kk
<Tobi> of those it doesn't drag in anything through headers
<abma> jK: yes, i tried after your change, i got one linker error :-/
<abma> + linking took ages.. >10 minutes or so
<hoijui> thing is.. if we have a simple source file, it will be that file itsself, the testign log sink, and if it uses a config value, it will be 3 files more
<hoijui> its not about headers only, but for compiling
<Tobi> yeah I see where you are going, good points
<abma> it was complaining about some missing math function, i'm unsure it was something like "undefined symbol: _tan" or so
<Tobi> ideally config values would be injected into the tested classes I'd say
<jK> <abma> + linking took ages.. >10 minutes or so > tried LTO-WHOPR?
<hoijui> yeah true
<hoijui> i also though of soemthing liek that
<Tobi> although when I extrapolate that we end up with reading all the 264 config vars in SpringApp and passing them to a bunch of classes
<abma> jK: no
<hoijui> mmm....
<jK> LTO-WHOPR should optimize/speed up optimization of huge projects (duno if spring is huge in their minds)
<hoijui> i dont follow anymore :D
<hoijui> i though about specifying config values in the testing code
<Tobi> [ARP]hoijui_g5: I mean if no classes read their own config vars anymore, but get the values through DI, then the top level class will have to read all 264 config vars and inject them into all other classes
<jK> IIRC it failed on some boost stuff when I tried it with GCC4.5
<Tobi> which would also be a bit silly design
<hoijui> mmm
<hoijui> yeah true
<Tobi> hoijui: if we want to push testing forward (I would like it) I would happily add a kind of mock ConfigHandler
<hoijui> :-) nice, thanks!
<hoijui> yeah... does probably not have to be right now
<hoijui> maybe after ILog is in, i will commit my two local tests, after refinign them a bit
<Tobi> that would supports the minimum to compile files, but doesn't touch any actual configuration etc.
<hoijui> none of them uses configuration
<Tobi> are you using a test framework?
<hoijui> yeah, boost
<Tobi> ok
<hoijui> i am not sure if i use it right..
<hoijui> i kind of use very little of it so far
<hoijui> but it kind of works
<hoijui> each test ends up as a separate binary, and test functions get executed
<Tobi> hmm
<hoijui> .. hwen manually onvoking the binaries
<hoijui> invoking*
<Tobi> could be there is a test runner somewhere that automates some of it
<abma> ->buildbot
<Tobi> I compared a bunch of test frameworks quite a while ago, but I forgot lots of it :/
<hoijui> yeah
<Tobi> abma_irc: buildbot is on top of that yeah :)
<hoijui> i remember we discussed them here once, and i think we agreed on boost looking best, with one other comming close
<hoijui> but maybe we should have very few tests until we are sure it is what we want
<Tobi> funny thing is I was playing with the idea to pick this testing up again too sometime, just didn't want to make the scope of my config branch a lot bigger suddenly :)
<Tobi> no
<hoijui> mmm :-)
<Tobi> I realized a while ago that not testing because its unclear which testing framework is best is bad, even better would be to hack together your own test framework
<hoijui> :D ok
<hoijui> mm also true
<Tobi> so even if boost test isn't perfect, it is still infinitely better than no tests at all
<hoijui> it seems pretty simple, especially compared to msot other boost stuff
<hoijui> bascially once include and a macro to call
<hoijui> and then asserts
<hoijui> and link agasnt the boost testing lib on cmake
<hoijui> shoudl be easy to change even if we had lots of tests
<Tobi> probably shouldn't be more than a bunch of sed -i yeah
<Tobi> (I even fixed those 50 bool-disguised-as-int config vars using a ~5 line sh script ;-))
<abma> jK: compiled with LTO+ LTO_WHOPR: http://pastebin.com/dr28G5Pc
<hoijui> wow.. cool! :D
<abma> ehm, some different
<abma> i'm unsure who asked, i guess it was koshi

conclusions:
  • the new config system is pretty much ready, and it comes well equipped ;-)
  • Tobi will (somewhen) look into how to make it well suited for unit testing
  • config key descriptions have to be added by everyone
  • (unrelated) compiling spring with LTO is slow/fails



Deprecate AllowStartPosition callin?
<Tobi> (ok, it was 12: http://pastebin.com/tzPtbkF2)
<abma> this callin is used to set start-point markers at the beginning
<abma> most mods have a widget to remove the markers...
<hoijui> hehe :D wow.. ok..
<hoijui> i would not have been able to dod that, woudl have used awk
<jK> why the hell deprecate it?
<jK> it should be used ways more
<Tobi> *Allow*StartPosition is used to set markers?
<abma> hmm
<abma> ok, i'm not really familar with this
<Tobi> well it wouldn't surprise me at all
<abma> if its nonsens, he meant to remove the marker
<abma> that makes more sense
<Kloot> I think it refers to http://springrts.com/mantis/view.php?id=2520
<abma> doh, yes
<abma> thx kloot
<Tobi> ah yeah we can do without that IMHO
<abma> without marker?
<abma> anything against removing?
<abma> (the marker)
<Kloot> no
<abma> ok
<Kloot> suppose someone will have to widgetify them to prevent "omg where did startpoint markers go" reactions
<zerver> :)
<jK> isn't trepan's widget already part of the defautl widget collection of spring?
<Kloot> minimap startboxes is
<Kloot> nothing that adds markers (anymore, he deleted many of them)
<jK> minimap startboxes draws markers
<Kloot> oh right those cones
<jK> only text is missing
<jK> nvm even that is drawn

conclusions:
  • abma will replace the engine supplied minimap widget with a start-pos-marker widget (default off) (DONE)



seined or unseined, that is the queschtion here!
<hoijui> Tobi, should i use int or unsinged int for the log level?
<hoijui> i guess int, right?
<hoijui> might come in handy to have -1 for something, some day
<Tobi> yes int
<Tobi> I hate unsigned int
<hoijui> :D
<abma> kloot: you saw my pull request to kaik?
<Tobi> it's only good for causing bugs like accidentally looking forever or accidentally allocating 4G of memory
<Tobi> *looping
<hoijui> :D
<hoijui> mm
<hoijui> it is also bad in C APIs (eg unitsync) for inter language problems (eg wiht Java)
<Tobi> yeah
<Tobi> it would be better if there were no implicit conversions between signed and unsigned types, but alas, there are
<hoijui> mmm
<Kloot> uints are nicer for stuff that can/should never be negative tho (id's / loop counters / sizes / array indices / etc)
<Tobi> I don't agree
<Kloot> you save at least the < 0 guard
<Tobi> I've seen too often bugs cause ppl use them anyway in calculations that may have a negative result
<Tobi> which then suddenly becomes mega large
<Tobi> at least one spring crash was caused by that :P
<Kloot> yeah that often happens with offset calcs
<hoijui> mm... in programming stuff, i trust the creators of Java... and they seem to think unsinged is not required ever
<hoijui> (hail!) :D
<Tobi> well I don't agree with that either :P
<hoijui> hehe
<Tobi> very occasionally they are good, but usually a source of bugs :P
<hoijui> that sounds like .. when they are good, you coudl write a special class for them, or write it in C or the like :D
<zerver> i also like the < 0 check uint can save
<hoijui> as it happens so seldomly
<Tobi> bitmasks and unsigned char for byte data cover 99% of the cases where they are good :)
<jK> they are only a source of bugs because/when gcc autocast them
<Tobi> yep
<Tobi> and that is required by the standard
<BrainDamage> yes, that was a really poor choice
<Tobi> binary op with one unsigned operand means the other operand gets implicitly converted to unsigned too
<Tobi> even if it is negative
<jK> standard fails (same for char/string)
<abma> Kloot: ...hm?
<Tobi> yup
<hoijui> cppcheck should have tests for that
<Kloot> eh no, just saw it now
<abma> aah, ok :)
<Tobi> I'd even argue to make your own UnsignedInt class with only explicit conversion to int to fix it, but that may go a bit far :P
<hoijui> hehe :D
<jK> there should be a `c++-w/o-c-backward-support`
<Tobi> yeah it would be great to turn off a few of those nasty implicit conversions
<Tobi> here, example of the silly things ppl will do with unsigned:
<Tobi> - const unsigned int mode =
<Tobi> - (unsigned int)std::max(0, std::min(modeIndex, (int)camControllers.size() - 1));
<hoijui> :D
<Tobi> now I hope git blame won't reveal I wrote that 5 years ago :P
<jK> lol
<Kloot> for me the worst part about that is the redundant cast
<hoijui> :D :D
<hoijui> i did not do minutes for a long time, guess its time again
<Tobi> another one: put -1 for some config option that is read as unsigned int
<Tobi> spring will see 4294967295 without any complaints
<Tobi> regardless whether it is correct or saves one cmp instruction it isn't what is expected
<Tobi> if there is no upper bound for the setting then that is the thing that will result in an infinite loop or near-infinite memory allocation somewhere
<hoijui> btw.. everyone is here, and everyone said soemthing!
<jK> k gamasutra answers seem to be finished
<jK> everyone can take a short glance and fix errors he finds?
<Tobi> ok
<Tobi> sorry to continue on it, but I want to add a last thing to the unsigned discussion: I think the problem is that people see unsigned int too often as IntThatWillClampNegativeValuesToZero, instead of what it really is: IntThatWillChangeNegativeValuesToArbitraryLargePositiveValues
<hoijui> hmm..
<hoijui> etherpad works really bad right now
<hoijui> is it cuase we all try to edit the smae thing?
<zerver> :)
<hoijui> i am not sure caseu. i felt it worked bad since some days already
<zerver> or is it the server again maybe
<Tobi> server as a whole is ok
<Tobi> etherpad is eating a core though
<zerver> i know that etherpad is very sensitive to high ping
<abma> jammi
<hoijui> shit :D
<hoijui> i copy pasted whole meetign log into etherpad
<Tobi> that must be it ;-)
<hoijui> no idea how that happend
<zerver> aargh
<hoijui> this happend like 4 times in the last few days, without me wanting it
<hoijui> only in etherpad
<hoijui> it must be stealing my clipboard!
<hoijui> traitor!
<hoijui> cant reconnect to revert it :D
<hoijui> sorry :D
<zerver> gtg gn8
<Tobi> does there exist a console jvisualvm?
<hoijui> what? :D
<hoijui> night zerver
>> <zerver> left!
<Tobi> so I can stare at ascii art graphs of cpu usage vs gc cpu usage
<Tobi> of java apps
<hoijui> ah
<hoijui> no idea
<hoijui> java is so fast, that i never had performance problems in the last 15 years -> never had to use profiler or the like
<hoijui> :D
<Tobi> when you get low on memory it blows up
<hoijui> mmm
<Tobi> GC starts to eat 99% of your cpu time for quite a while until finally you get a GCOverheadExceededException. Or an OutOfMemoryException ofc :-)
<BrainDamage> or kill -9 pid from an angry sysadmin
<Tobi> :)
<hoijui> :D
<hoijui> hmm ok.. never saw GCOverheadExceededException so far
<Kloot> there should be JavaTooManyExceptionsException
<abma> BrainDamage: who got spring compile with lto?
<Tobi> :)
<Tobi> I'll restart it
<BrainDamage> tizbac iirc
<abma> ok
<hoijui> :D :P

conclusions:
  • sein(ed)!!!
Last edited by hoijui on 06 Jul 2011, 00:58, edited 1 time in total.
User avatar
zwzsg
Kernel Panic Co-Developer
Posts: 7049
Joined: 16 Nov 2004, 13:08

Re: Dev meeting minutes Monday, 4. July 2011

Post by zwzsg »

<Tobi> - automagic clamping if minimum/maximum value have been specified
I hope I can still use negative ScrollWheelSpeed !
User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Dev meeting minutes Monday, 4. July 2011

Post by Licho »

When changing logging, please try to avoid changing log messages themselves, and if you do, please mention it loudly :)

Lots of things depend on parsing infologs:

* gameid reading to connect demo with game
* ally chat and points reading for text to speech on client
* mission score
* planetwars stuff
* modstats
* error reporting

inconsistencies between dedicated server and full spring are also hurting atm - for example dedicated server wont publish gameid anywhere so its not possible to learn it.
User avatar
Licho
Zero-K Developer
Posts: 3803
Joined: 19 May 2006, 19:13

Re: Dev meeting minutes Monday, 4. July 2011

Post by Licho »

As for multi-engine support, i disagree with lobby server implementation (hiding games from lobbies that dont support it) -> I dont plan to conform to it in near future and plan to keep using [enginex.y.z] in game title.

Hiding games imo does more hurt than it solves.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Dev meeting minutes Monday, 4. July 2011

Post by knorke »

on the startposition markers: http://springrts.com/mantis/view.php?id=2520
What I meant was just removing those "start 0" etc markers put by the engine at game start.

If a widget is made to replace this function then it should imo not be shipped with the engine install. Instead just make available like the game_spawn.lua and then the games who want this, can grab it and include it in the mod file.
Even if it is disabled by default, it puts more clutter in the F11 list of games who do not use it.

I did not mean those markers used in the "chose start positon" phase of the game, before clicking ready. Though thinking about it, maybe even those could be game Lua side if AllowStartPosition was documentated.


Some other widgets that are currently included in the engine but could be mod side only:
unit_factory_guard.lua
unit_immobile_buider.lua
unit_metal_maker.lua
unit_stockpile.lua

Those are very game specific, imo no need to have those in the engine.

Then they are some, which are can be usefull for basically every game:
gui_xray_shader.lua
gui_team_platter.lua
gui_selbuttons.lua
gui_hilight_unit.lua
camera_smooth_move.lua
camera_shake.lua

But even those do not really need to be in the engine?

Actually almost all widgets could be removed, except maybe headless_setup.lua

/edit
made mantis: http://springrts.com/mantis/view.php?id=2537
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Dev meeting minutes Monday, 4. July 2011

Post by smoth »

Please edit the seperatoe lines it is hard to read
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Dev meeting minutes Monday, 4. July 2011

Post by FLOZi »

+1 to knorke, also:
<jK> minimap startboxes draws markers
<Kloot> oh right those cones
<jK> only text is missing
<jK> nvm even that is drawn
So no need for extra widget?
User avatar
hoijui
Former Engine Dev
Posts: 4344
Joined: 22 Sep 2007, 09:51

Re: Dev meeting minutes Monday, 4. July 2011

Post by hoijui »

i agree with knorke, that the marker widget should not be included by the engine.

Z and Licho:
... easy guys!!

smoth
... as precise as in your mantis reports.
no idea what you are talking about.
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Dev meeting minutes Monday, 4. July 2011

Post by smoth »

hoijui wrote: _Agenda_____________________________________________
smaller please.
cleanrock
Former Engine Dev
Posts: 115
Joined: 21 Feb 2009, 07:42

Re: Dev meeting minutes Monday, 4. July 2011

Post by cleanrock »

If u missed google-glog (for logging) u should check it out:
http://code.google.com/p/google-glog/
User avatar
CarRepairer
Cursed Zero-K Developer
Posts: 3359
Joined: 07 Nov 2007, 21:48

Re: Dev meeting minutes Monday, 4. July 2011

Post by CarRepairer »

Knorke your post started out well then went downhill. All those widgets are useless in some games and would interfere with the game's interface. Remove ALL widgets from the engine please. This should have been done years ago.

I heard spring is an engine, not a game.
User avatar
FLOZi
MC: Legacy & Spring 1944 Developer
Posts: 6240
Joined: 29 Apr 2005, 01:14

Re: Dev meeting minutes Monday, 4. July 2011

Post by FLOZi »

CarRepairer wrote:Knorke your post started out well then went downhill. All those widgets are useless in some games and would interfere with the game's interface. Remove ALL widgets from the engine please. This should have been done years ago.

I heard spring is an engine, not a game.

Your reading fails, cos I read this from knorke's post:

But even those do not really need to be in the engine?

Actually almost all widgets could be removed, except maybe headless_setup.lua

:wink:
Tobi
Spring Developer
Posts: 4598
Joined: 01 Jun 2005, 11:36

Re: Dev meeting minutes Monday, 4. July 2011

Post by Tobi »

zwzsg wrote:
<Tobi> - automagic clamping if minimum/maximum value have been specified
I hope I can still use negative ScrollWheelSpeed !
I don't plan to introduce any new minimum/maximum values.
User avatar
liamdawe
Posts: 120
Joined: 19 Mar 2010, 15:09

Re: Dev meeting minutes Monday, 4. July 2011

Post by liamdawe »

Tobi wrote:
zwzsg wrote:
<Tobi> - automagic clamping if minimum/maximum value have been specified
I hope I can still use negative ScrollWheelSpeed !
I don't plan to introduce any new minimum/maximum values.
So was that a yes to his question, it won't affect using negatives?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Dev meeting minutes Monday, 4. July 2011

Post by smoth »

FLOZi wrote:
CarRepairer wrote:Knorke your post started out well then went downhill. All those widgets are useless in some games and would interfere with the game's interface. Remove ALL widgets from the engine please. This should have been done years ago.

I heard spring is an engine, not a game.

Your reading fails, cos I read this from knorke's post:

But even those do not really need to be in the engine?

Actually almost all widgets could be removed, except maybe headless_setup.lua
:wink:
And start boxes because that is forced on all projects.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Dev meeting minutes Monday, 4. July 2011

Post by knorke »

i dont use startboxes.
only some lobbies/autohost force them but they have no meaning ingame.
also what if instead of red/green startboxes you want purple ones?
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Dev meeting minutes Monday, 4. July 2011

Post by smoth »

Until we have more control over what shit can be force on our games yeah it needs to stay. Start boxes are one of those things.
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Dev meeting minutes Monday, 4. July 2011

Post by knorke »

and then someday lobby/autohosts supports getting set to "fixed only" but the engine will still have the stupid minimap startbox widget.
just c&p it into your mod...
User avatar
smoth
Posts: 22309
Joined: 13 Jan 2005, 00:46

Re: Dev meeting minutes Monday, 4. July 2011

Post by smoth »

How are you going to stop me from using them in your mod? Host match dsd e vs w startboxes. If you don't have them what happens?

I feel that you are opening a potential land mine..

Of those graphics.. Engine doesn't need seismic gfx

Oh those tree textures but the engine doesn't need those
User avatar
knorke
Posts: 7971
Joined: 22 Feb 2006, 01:02

Re: Dev meeting minutes Monday, 4. July 2011

Post by knorke »

Host match dsd e vs w startboxes. If you don't have them what happens?
This happens:
Image
(if there was a lobby that reads and obeys validmaps.lua, you could not even select DSD in the lobby.)

And if the map is supported, it will ignore where players placed their makers and put them on pre-defined positions.

At the moment, the F11 list for my game looks like this:
f11 list.jpg
f11 list.jpg (49.83 KiB) Viewed 3472 times
Basically I only want the green ones, I do not need any of the red ones but I can not remove them from the list. (yes, 1 or 2 in that picture are custom, does not matter)
There are ways to blacklist/whitelist widgets but they will still show up in the F11 list.
If a player wants to place a metalmaker_manager.lua into this widgets\ folder which then does nothing because there are no metalmakers, fine for him. But why should that be in the engine?
And its the same with startboxes.
Oh those tree textures but the engine doesn't need those
imo the engine does not need trees. Why should it have trees but not rocks? Difference is, some unused textures do not bother me.

+1 for adding anti_comnap.lua to the engine!
Attachments
mapnotsupported.jpg
(16.66 KiB) Downloaded 2 times
Post Reply

Return to “Meeting Minutes”