Present: zerver, hoijui, Tobi, abma, jK, abma
agenda:
* release plan
* buildbot: sjlj vs. dwarf2
* Ask community for a macosx host to fix spring on it
* folder-structure for a installed spring (win32)
_Welcome__________________________________________________________
<abma>hey!
<abma>monday + etherpad isn't working :)
<abma>thx, now it works :)
<abma>hmm.. got some network problems :-/
<abma>hi again! :)
<zerver>thx
<jK>hi all
<abma>i'll do
<zerver>i can do that
<abma>its fine, i'll do
_Release plan_______________________________________________________
<abma>anything new about that?
<zerver>apparently not
<zerver>im wondering if we are doing too many .82 releases
<jK>many of those never were released to the users
<jK>problem is just that master & 0.82 differ a lot know and rebasing isn't that easy anymore
<jK>*now
<abma>hmm, then better try to make a (test) release from the master branch
<jK>don't see a 0.83 in <3months
<abma>yep, sure
<abma>with test-release i mean a "work in progress" release or so...
<abma>hm, for that the next point is important, as currently cross-compiling doesn't work on the buildbot
<zerver>exactly what is it that would take 3 months to fix?
<jK>dynsun, sound interface bugfixes, ...
<zerver>dynsun? not really
<jK>dynsun as is, is not releasable
<zerver>that may be true, but 3 months?
<jK>there are a lot of such `small` issues
<jK>kloot's removed lua unitdef types are breaking lua scripts etc. (backward compability needs to be added ...)
<zerver>i wasnt able to reproduce the "dark" map btw
<jK>check charlie in the hill v2
<zerver>ok
conclusion:
looks like there will be no 0.82.x release, because backporting bugfixes is difficult because of many changes in master. We try to make a test-release from master and make then, if the bugs there found are fixed, a 0.82.3 release in maybe ~3 months. (just a guess)
_buildbot: sjlj vs. dwarf2_____________________________________________
<jK>tobi, there?
<zerver>sjlj sucks iirc?
<jK>`sucks` is a bit strong
<jK>mainly it is a question of how hard it is to get dw2 working on ubuntu
<zerver>it crashed when throwing exceptions in more than one thread
<abma>afaik the problem is: dwarf2 is used as default for win32mingw, sjlj is used as default at least on ubuntu
<jK>o_O that's new info for me (sjlj not being threadsafe)
<jK>*to
<zerver>im positive that is what we had problems with last time, but maybe they fixed it?
<jK>hmm tobi?
<Tobi>exception handling occasionally wasn't thread safe indeed
<Tobi>I don't recall if that was related to sjlj per se or just a bug in a certain gcc series..
<zerver>could be
<zerver>still would avoid switching to sjlj unless absolutely necessary
<jK>oh you don't know?
<Tobi>would a recompile of ubuntu mingw package with --disable-sjlj --enable-dwarf2 be sufficient? (anyone experience with that?)
<jK>we are using sjlj atm!
<jK>yeah tobi, that's enough
<jK>compiled it myself on gentoo this way
<Tobi>or rather <lurker[]: --disable-sjlj-exceptions --with-dwarf2
<jK>(and checked the resulting libs for sjlj/dw2)
<Tobi>silly inconsistent parameters if it's really that
<jK>I wonder why it is not a runtime param
<Tobi>good question yeah :)
<hoijui>i guess it woudl create jsut more confusion
<hoijui>eg.. this way the ubuntu folks can somewhat stear thigns.. all mingw compiled libs to use the same
<hoijui>same for other distros
<hoijui>or at least that is a way to reason
<abma>i'm still search for why linux-distributions seems to perfer sjlj
<jK>I assume it is related to ARM/RISC cpus & linux
<jK>(dw2 is x86 only)
<zerver>ok
<Tobi>native linux binaries use sjlj too then by default? or are we only talking about mingw crosscompilers?
<hoijui>only mingw
<jK>yeah, from what I know linux itself uses sjlj by default
<abma>mingw and/or crosscompile
<Tobi>[LCC]jK: how did you check for sjlj/dw2? just nm -U | grep -i sjlj or so ?
<hoijui>ouh
<jK>yep, checked it with grep
<Tobi>ok, then I will try to do that asap
<jK>:)
concusion: tobi tries to compile mingw on the buildbot with dwarf2 enabled
_Ask community for a macosx host to fix spring on it?__________________
<jK>k we got such an offer, still the conditions aren't super
<jK>I dislike to dev on someone else's desktop
<jK>I would prefer a vm solution. Crappy Apple EULA disallows that except for their Server editions, but I don't know if those clauses are valid outside of the USA
<jK>btw the SDL framework on the builbot OSX client need to be fixed (it's 32bit only and XCode needs 32+64bit ones)
<zerver>k, not too many opinions on that it seems
<jK>hehe
<zerver>maybe need some dedicated osx dev for that to take off
<jK>yeah, an extra osx dev would be the best (esp. because we have quite less knowledge of xcode & co)
<jK>but afaik osx devs are rare and most want money >_<
<zerver>because their hardware costs so much
<jK>lol
<hoijui>you still need special hardware, even though it runs on intel now? GPU?
<zerver>price dropped a bit when the 100% SCSI interface was abandoned at least
<jK>erm legally (in the us) you `need` their hardware
<hoijui>ah
<jK>technicaly no
<jK>yeah, there was something with scsi
<jK>but I can't think that all their notebooks have scsi
<jK>so need to support sata these days
<zerver>indeed, there are so few SCSI products available
<jK>and they are extremely expensive (esp. because many advantages of it are available with SATA too)
<zerver>SCSI pwned before UDMA became really good
<abma>in short: we need: full ssh and VNC access to a (at least virtual) macosx-machine, 24/7, to fix the macosx issues. (but we can't guarante that we'll fix)
<jK>even with UDMA SCSI had it reasons (DMA, better protocol, ...)
<zerver>in short we have an open position for the osx dev too
<abma>:)
<abma>hopefully someone answers this call.. so next
conclusion: we need help to fix the macosx build, either we need patches or a macosx host accessable 24/7 with vnc + ssh + root access (all other solutions aren't fun and we all develop spring for fun/in our free time) we would be very happy if someone could help with that!
(sorry, we can't guarante that we'll succeed in fix spring on macosx)
__folder-structure for a installed spring (win32)________________________
<abma>currently its hard to install multiple versions of the engine on windows
<abma>because the installer ships with lobbies/rapid/...
<abma>i would like to install this stuff outside of the engine folder
<jK>first, we need to reintroduce a regkey, lobbies can use to find the unitsync.dll
<jK>-,
<jK>this way lobbies & tools can be installed outside of the spring-dir
<hoijui>the idea of the launcher is, that it would allow accesss to all the instaleld engine versions
<abma>that can be easily added to the installer
<hoijui>unitsync would likely use a similar mechanism
<hoijui>though it is simpler there
<jK>yeah, but unitsync is the gate of a launcher
<hoijui>?
<jK>unitsync gives lobbies all information they need
<hoijui>yeah
<jK>w/o knowing where those files are located
<hoijui>i mean launcher.exe, not lobbies
<jK>so lobbies just need to know the unitsync.dll
<jK>from that we can then start to reorganize the spring folder to support diff versions of base content etc.
<hoijui>there woudl be a launcher unitsync, and the real implementations (one per version)
<hoijui>thats what i meant
<hoijui>launcher is maybe not a good name there
<abma>maybe wrapper?
<jK>or extend the unitsync to switch versions?
<abma>the lobbies currently start spring.exe with some parameter
<hoijui>how woudl it switch versions?
<hoijui>in both scenarios you assume that unitsync does not change
<jK>the only reason why you would need multiple unitsyncs are the checksums, and when you can switch between spring version in the unitsync, it's not needed
<hoijui>between versions
<jK>or we make checksums basecontent independent as Licho requests for a very long time now
<jK>then all spring versions can use the same unitsync
<hoijui>yeah, that should be done anyway
<hoijui>but no
<abma>imo, the same unitsync for all spring versions is currently to much work
<hoijui>yeah ok... that coudl work, but unitsync changes.. new features, bug fixes..
<abma>or i don't see the clean way
<hoijui>so different lobbies/lobby versions will want to use different unitsync versions
<jK>unitsync changes are rare
<hoijui>using the same principle for untisync liek for the launcher is also more unitform
<jK>and they should be backward compatible anyway
<jK>why should the engine manage multiple unitsyncs?
<jK>-engine +lobby
<hoijui>that is just nto the case in practise, and it will not be, so we can not assume that
<jK>it is a lot of work to handle diff unitsync in the lobby
<hoijui>does not have to manage it
<hoijui>but has to be able to choose which one to use
<hoijui>what is the problem wiht that?
<jK>they, have to load/unload, manage their output in databases, ...
<hoijui>i can not see any
<jK>-,
<jK>each on is its own dll and all have to be loaded (with namespace conflicts!) and unloaded when you want to runtime switch the version
<jK>*each one
<hoijui>it does not have to be reloaded at runtime
<jK>when you join a host with a diff spring version?
<hoijui>the unitsync has to fit to the lobby, not to the spring version
<hoijui>the lobby can choose which one to use
<hoijui>one wiht less bugs, or with more features, or with interfaceX isntead of Y
<jK>o_O
<hoijui>again.. what is the problem?
<hoijui>it is the smae mechnaism liek for launcher, so no added complexity
<jK>now it doesn't make sense anymore at all
<jK>if the unitsync output should be spring version independent
<jK>then why to have multiple unitsyncs at all?
<hoijui>because output format of fucntions changes, paramters change, new functiosn get added, old ones removed
<jK>it would it be like we would still ship all 0.69-0.82 unitsyncs in the current installer
<hoijui>that is reality
<abma>unitsync output changed from time
<jK>and then lobbies need to update
<jK>not more, not less
<hoijui>hey jk.. what is the problem wiht my solution?
<hoijui>it fixes issues from reality, but has no harm..
<hoijui>or at least you did not mention any
<jK>I see much trouble with it
<hoijui>crystal ball?
<jK>multiple unitsync branches no one wants to maintain (you don't want to recommit your change to the unitsync to 5 branches)
<hoijui>aehm...
<hoijui>i think you dont get it
<jK>nor do you want to support 3did APIs
<hoijui>that woudl not be the case
<jK>-did +diff
<abma>spring 0.83 ships with unitsync 0.83
<hoijui>only
<abma>0.82 with unitsync 0.82 ...
<hoijui>but if you had 0.82 isntalled, the old untisync stays
<jK>yeah but that 0.83 unitsync has to be able to handle 0.82, 0.81, ... too
<hoijui>and TASCLient, which is not updated to work with 0.83 untisync, still works
<hoijui>no
<abma>no, imo that won't work
<abma>0.82 has to handle 0.82 and only 0.82
<hoijui>yeah
<jK>so old lobby won't be able to handle/start any future spring versions ...
<hoijui>no
<hoijui>it may not be able to use newer unitsync
<abma>if abi/api breaks, yes.. if unchanged it will work
<jK><abma_irc: 0.82 has to handle 0.82 and only 0.82 : that what I talked a full page about!
<hoijui>so cant use new untisycn features
<jK> <[LCC]jK: each on is its own dll and all have to be loaded (with namespace conflicts!) and unloaded when you want to runtime switch the version
<hoijui>only one is loaded at a time
<jK>so if you want to support multiple spring version in the lobby (and being able to switch between them at runtime), then you need either a uniform unitsync that can handle all versions OR you need to load/unload them at runtime
<jK>and the 2nd is not an option as explained above
<hoijui>you need all unitsyncs to suport all versions of sprign, yes, but you do not need there to be only one unitsync
<jK>so the 0.83 unitsync needs to be able to copy the behaviour of all previous unitsyncs (on the input side, not output)
<hoijui>NOOO
<hoijui>it only has to suply the same basic info
<hoijui>and even there not quite
<hoijui>lets say, old versions include base content in checksums, new ones not
<jK>no, you need to be able to start&manage 0.82 matches with the 0.83 unitsync too
<abma>then we've two solutions: lobby needs to support multiple unitsync versions or add a (never changing) wrapper/lib for that?
<jK>so it needs a 100% copy of the 0.82 one
<hoijui>what do you mean wiht matches?
<jK>only battles/matches/games
<hoijui>ahh games..
<hoijui>duh
<jK>*online-
<hoijui>sorry..
<hoijui>yes true that
<zerver>i suggest to make a new unitsync that can act as some kind of proxy for various unitsync versions, but also is backwards compatible
<hoijui>lets say, 0.82 has a functions called getChecksum(), and we rename it to getGameChecksum() in 0.83 (i know, bad idea, but that does not matter)
<hoijui>tasclient supports old way only
<Tobi>what is wrong with simply keeping unitsync backward compatible? that has worked until now?
<hoijui>SL the new one
<zerver>i agree, it should be backwards compatible
<hoijui>of course
<hoijui>nobody disagrees
<hoijui>but no, it has not always worked till now
<jK>currently it is not 100% backward compatible (mainly because of basecontent related checksums)
<hoijui>what i propose just adds value, and costs us nothing
<jK>but when that got fixed/changed, only 1 unitsync is needed
<hoijui>like.. wehn satirik or any TASC user comes yelling at us, cuase we brokoe TASC
<hoijui>that wont happen anymore in the future, wiht my solution
<jK>hoij, until now it worked by forcing lobbies to update on unitsync changes
<hoijui>with my solution, we will not see this issue, so far, we have seen it
<hoijui>so no, it did not work
<hoijui>we release, everyone gets pissed, it starts to get adjusted
<jK>instead we would see a maintaining problem on our side
<hoijui>with my solution, that is not happening
<hoijui>no
[ARP]hoijui_g5 [LCC]jK [RoX]Tobi
<hoijui>becuase as i said, it uses the same mechanism as launcher
<hoijui>so no added complexity
<abma>[ARP]hoijui_g5: can you explain your solution a bit more, please?
<hoijui>there woudl be a single untisync.dll launcher-wrapper, wiht one function
<hoijui>you call that function with one parameter: version
<zerver>i agree with that "launcher" unitsync, but it should not be a pure launcher, but rather a real unitsync that can also be a proxy for the various installer unitsyncs if lobby asks it to do that
<hoijui>adn it loads unitsync-version, for example
<hoijui>that makes no sense zerver
<hoijui>the user will nto see a difference (user beeing the lobby)
<Tobi>proper solution is to have automated tests on the external api... not extra (untested) layers of complexity
<abma>zerver: the proxy sounds like an unmaintainable beast
<hoijui>welll.. testing that extra complexity (which is basically nothing) is like 0.001% of the tests you suggest (whihc would never happen in reality, as they woudl be requried)
<hoijui>and we need that complexity for the engien launcher anyway
<Tobi>engine launcher is quite a bit easier I'd say (less APIs)
<Tobi>isn't it?
<hoijui>the launcher does not have to worry about the API
<hoijui>it just has to load
<hoijui>nothign else
<hoijui>maybe unload
<Tobi>for unitsync like 50 methods need to be proxied, launching engine is just that, launching one executable
<jK>the launcher could even be a func in the unitsync
<hoijui>they have to be proxied?
<Tobi>(regardless of whether there is a real proxy dll or the proxy is implicit, e.g. by the lobby dynloading the dll)
<hoijui>i though that not
<hoijui>if yes.. then yeah... that would not work
<hoijui>so whn you dynload a dll, which dynloads an other dll, you can not access that dlls functions?
<hoijui>when*
<jK>afaik there is no way to just link all external functions of a dll, you always need to add std_call links on the loading side
<hoijui>unitsycn has to be dynloaded anyway
<jK>so when the proxy dll needs to load all those functions, then it needs a long list with all of them
<hoijui>cant statically link to it
<hoijui>at least shoudl not
<abma>currently it is dynamicly loaded
<hoijui>thats what it is compiled for
<hoijui>what it shoudl be
<jK>weren't talking about static/dynamic linking
<jK>we talk about implicit dll function loading
<hoijui>if the wrapper/proxy/launcher dll needs to proxy the functiosn, the thing does not work
<Tobi>loading the address of functions dynamically and storing them in function pointers
<hoijui>yeah
<hoijui>you say, that woudl not work?
<hoijui>with a prixy?
<hoijui>proxy
<jK>(implicit -: no GetUnitdyncFuncAddr() needed)
<hoijui>without wrapping?
<Tobi>that would, but the proxy would need to have a method for every proxied method
<Tobi>have you seen e.g. the way SL loads unitsync?
<hoijui>yes
<jK>and you can't overload those different versions
<Tobi>what do you mean?
<jK>-: you were never be able to switch function params
<jK>*will be
<zerver>just need a "SetVersion" function in the unitsync to make it act as a proxy
<zerver>if that function isnt called, it acts as a regular unitsync
<Tobi>please don't make it double purpose
<Tobi>that's just confusing
<hoijui>it is simple
<Tobi>make a separate proxy dll if a proxy is desired
<hoijui>if it needs proxies for each function, it does not work
<zerver>the user should be able to install the lobby directly in the engine directory also, to have different lobbies installed at the same time
<hoijui>so lets jsut make this clear
<hoijui>if i got tobi right, it needs proxies, but eveyrone else is talkign abotu stuff that really does not matter here
<jK>or you just don't understand 'everyone else'
<hoijui>implicit loading does nto matter here, for example
<jK>it does
<Tobi>well proxy may be an overloaded term here, but at least there must be an extra level of indirection compared to what is required now
<zerver>:) but i said proxy too, so that should matter
<Tobi>if a single lobby is to switch unitsync version at runtime
<hoijui>... that is not the goal (it coudl in theory be a nice addon, if it woudl work)
<hoijui>the question is:
<hoijui>A.dll loads B.dll, which exports funcX()
<hoijui>lobby does: load(A.dll); getFuncPointer("funcX");
<hoijui>does this work?
<zerver>no
<jK>not with implicit loading (and w/o extra code)
<hoijui>A.dll does load(B.dll)
<hoijui>ok
<zerver>the pointer cannot be passed, but the call can be proxied into the other dll
<jK>can't it?
<hoijui>..ahh
<jK>B.dll gets loaded in the same process -: shares the addr space
<hoijui>true that
<hoijui>the call can be proxied
<hoijui>if what jk just mentioned does not work (zerver and tobi say it does not, if i got them right)
<hoijui>i had the smae thoughs like you jk, about smae process, but am not sure anymore
<jK>problem is you never the less not using implicit loading anymore
<jK>+can
<hoijui>implicit loading is not used anymore already
<Tobi>actually I think what you state (the way you state it) does work
<hoijui>untisync is compiled as module, whihc menas it has to be dynamically loaded
<hoijui>so no call redirection needed even?
<jK>even dyn dll can use implicit linking
<zerver>yeah it could maybe work
<hoijui>hmm... ok... does tasc use that? SL does not (implicit loading)
<jK>it needs to be supported by the dll
<jK>so it's unlikely
<hoijui>we could have a function in the wrapper: getPathToRealUnitsync(version) :D
<abma>that was my initial idea about that
<abma>or read that from registry
<abma>or just use a version-based lib-name
<hoijui>both inferior solutions
<zerver>jK, the function pointer can indeed be passed, problem is there will still be two levels of indirection needed
<hoijui>OS dependent and less flexible
<zerver>GetProcAddress("functionlist") --: FindFunction("xxx")
<Tobi>I think it uses implicit loading
<zerver>and this makes it not backwards compatible
<zerver>so proxying of calls is the only backwards compatible method i think
<jK>yeah zerver, but that is just one function and not 20
<Tobi>or in any case the dll name is specified at compile time
<hoijui>compile time of what?
<Tobi>tasc
<hoijui>ah
<Tobi>function Init(isServer: Boolean; id: Integer): Integer; stdcall; external 'UnitSync.dll' name 'Init';
<Tobi>only 1 function is loaded explicitly if it is available only
<hoijui>if we choose a wrapper of any sorts, lobbies woudl have to adapt that one time to make it work, and if it is for nothing more the nchoosing which versions they want
<zerver>need two new functions in unitsync imo, "GetVersions" and "UseVersion"
<hoijui>that woudl be in the wrapper
<zerver>unitsync IS the wrapper :)
<hoijui>well.. for the engine versions we woudl need something liek that of course
<hoijui>no
(23:57] ** [LCC]jK left the channel( Quit: Exiting ).
(23:57] ** Server ** Disconnected from server, chat closed.
(23:57] ** Server ** Chat closed.
(23:58] ** abma_irc joined the channel.
<abma>strange connection problems today...
<hoijui>ahh
(00:01] ** abma_irc left the channel( Quit: Lobby connection timeout ).
<Tobi>this was the server I think
<Tobi>still huge lag?
(00:01] ** [LCC]jK left the channel( Quit: Exiting ).
(00:01] ** abma_irc joined the channel.
(00:01] ** [LCC]jK joined the channel.
(00:03] ** [LCC]jK left the channel( Quit: Exiting ).
<Tobi>it doesn't solve the real problem though afaics... which is that a lobby may break if an API changed unexpectely
<hoijui>i think yes
<hoijui>yes :D
(00:03] ** [LCC]jK joined the channel.
<jK>re
<Tobi>wb
<Tobi>[ARP]hoijui_g5: you mean you think it does solve that?
<hoijui>hehe :D
<hoijui>no, i meant the lag
<hoijui>.. still lag
<Tobi>ah
<Tobi>yeah can't even ssh in at the moment
<hoijui>i had an other idea: i still want to rename untisync, and when changeing to a wrapper woudl be a good time, it even helps in this way:
<hoijui>we keep a unitsync.dll, and make that a wrapper, which wrapps each function that exists right now (0.82) to the wrapper untisync
<Tobi>that would be a nice side effect yeah :)
<hoijui>the wrapper is called newname.dll, and wrapps newname_impls/versionX.dll
<hoijui>if a call redirect for the loadFunction("funcX") is requried, it will be required when using newname.dll only, not when using unitsync.dll, so unitsync.dll is still 100% backwards compatible
<Tobi>I propose we cancel meeting for now... too much lag...
<Tobi>oh wow that was fast
<abma>yep :-/
<jK>yup
<zerver>y
<jK>it's late too
conclusion: to allow multiple spring versions to be installed unitsync (and/or lobbies) needs some additional functionality, we disscussed some solutions but came to no conclusion because the lobbyserver had a giant lag at this topic, we have to continue discussion this point at next meeting
