--- Log opened Sun Feb 21 00:00:12 2010
20100221 00:00:24< YogiHH> fendrin: I will see about that
20100221 00:08:32< fendrin> YogiHH: mordante pointed me to the issue that the "use map settings" checkbox disables the locking of certain scenario preferences and the game can be started with kalenz or landar being an orc.
20100221 00:11:52< CIA-88> jhinrichs * r41312 /trunk/ (changelog src/playsingle_controller.cpp): Don't show the turn dialog once the scenario has ended. This should apply to both single player and multiplayer.
20100221 00:12:16< YogiHH> fendrin: Can you put the last one into the bugtracker and assign it to me?
20100221 00:14:09< YogiHH> night everyone
20100221 00:14:14-!- Shadow_Master [~ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100221 00:14:20< fendrin> YogiHH: sure, I do that. Another related issue is that every nonhost player is asked to select a faction but that dialog chose is going to be ignored later if "use map settings" is checked. I suggest a force_map_settings attribute that disables both, the possibility for the host to uncheck the button and the selection dialog for the other clients.
20100221 00:14:34< fendrin> YogiHH: Good night :-)
20100221 00:14:46< Crab_> YogiHH: good night :)
20100221 00:15:14-!- zookeeper [~l@wesnoth/developer/zookeeper] has quit []
20100221 00:15:14-!- Shadow_Master [~ignacio@wesnoth/developer/shadowmaster] has quit [Client Quit]
20100221 00:16:27-!- YogiHH [YogiHH@wesnoth/developer/yogihh] has left #wesnoth-dev []
20100221 00:20:54-!- gabm [~gabm@70.35.163.70] has joined #wesnoth-dev
20100221 00:31:39-!- shadowm_laptop [~ignacio@wesnoth/developer/shadowmaster] has quit [Quit: later]
20100221 00:46:00-!- Blueblaze [~nick@adsl-99-158-47-180.dsl.hstntx.sbcglobal.net] has quit [Remote host closed the connection]
20100221 00:46:31-!- silene [~plouf@ASte-Genev-Bois-152-1-5-240.w82-121.abo.wanadoo.fr] has quit [Quit: Leaving.]
20100221 00:52:26-!- Blarumyrran [~Blarumyrr@81-20-159-197.levira.ee] has quit [Quit: Lahkun]
20100221 00:56:37-!- gabm [~gabm@70.35.163.70] has left #wesnoth-dev []
20100221 01:00:44-!- MikeJB [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Quit: quit()]
20100221 01:04:58-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20100221 01:19:06-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100221 01:21:39-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100221 01:34:29-!- rolando [~rolando@150.116.108.93.rev.vodafone.pt] has joined #wesnoth-dev
20100221 01:39:43-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has quit [Remote host closed the connection]
20100221 01:43:18-!- ancestral [~ancestral@97-116-104-150.mpls.qwest.net] has joined #wesnoth-dev
20100221 01:46:10< ancestral> I'm curious — was there a reason that devs choose to use maps written in ASCII versus as binary files? Was a big part of it that they would be easier for players and modders to edit, or was it simply in place before there was even a map editor?
20100221 01:47:03< ancestral> I only ask from a game development standpoint; I'm working on a pet project and I'm just curious why Wesnoth chose to go the route it did, as many games use binary map files
20100221 01:59:24< AI0867> ancestral: probably pretty much that
20100221 01:59:34< AI0867> also the fact that they can be embedded in text files
20100221 01:59:46< AI0867> related: http://www.catb.org/~esr/writings/taoup/html/ch05s01.html
20100221 02:00:31< ancestral> Was it ever debated, moving maps to binary, or having a choice? Just as file size could be reduced significantly?
20100221 02:00:57< AI0867> not that I remember
20100221 02:01:09< AI0867> besides, text compresses well and disk is cheap
20100221 02:01:59< ancestral> This is true
20100221 02:02:26< ancestral> I'm trying to think of other games out there that are like Wesnoth in this regard, but I'm at a loss
20100221 02:02:37< ancestral> (commercial, shareware, freeware, whatever)
20100221 02:08:12-!- shadowm_laptop [~ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100221 02:09:15< Crab_> ancestral: civilization 4, for example
20100221 02:09:48< ancestral> Civ 4 does store most all its files in text… I never checked its map files
20100221 02:10:01< ancestral> BTW Civ 5 announced this fall…
20100221 02:10:10< Crab_> yes 
20100221 02:12:18-!- Zarel|laptop [~Zarel@c-75-72-160-179.hsd1.mn.comcast.net] has quit [Quit: Leaving]
20100221 02:13:53< shadowmaster> AI0867: text compresses well... when it's compressed ;)
20100221 02:14:18< shadowmaster> only the distribution packages are compressed, so maps can still take up a lot of space on disk when installed
20100221 02:14:23< AI0867> shadowmaster: I meant that having it in plain text on disk doesn't mean you have to download the full size
20100221 02:15:14< ancestral> Crab_: You are right though
20100221 02:15:16< shadowmaster> also, it seems to be natural for Dave to write map formats that can be embedded into string literals
20100221 02:15:56< ancestral> Crab_: Save game files are not, though, probably for a reason
20100221 02:16:10< shadowmaster> (thinking about Frogatto and Silvertree, although the latter doesn't embed them)
20100221 02:17:02< shadowmaster> esr's document is broken in Firefox 3.5
20100221 02:17:43< shadowmaster> well, s/(broken)/kinda $1/
20100221 02:23:27-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has quit [Quit: Zzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzzz]
20100221 02:24:03-!- loonybot [~loonybot@wesnoth/bot/loonybot] has quit [Remote host closed the connection]
20100221 02:24:05-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100221 02:37:54-!- shadowmaster_ [~ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100221 02:38:19-!- shadowm_laptop [~ignacio@wesnoth/developer/shadowmaster] has quit [Disconnected by services]
20100221 02:38:28-!- shadowmaster_ is now known as shadowm_laptop
20100221 02:51:58-!- Crab_ [~Crab_@wesnoth/developer/crab] has left #wesnoth-dev []
20100221 03:11:50-!- [Relic] [~Relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20100221 03:12:42< [Relic]> Hello :)
20100221 03:31:34-!- [Relic] [~Relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Quit: Leaving]
20100221 03:35:21-!- shadowm_laptop [~ignacio@wesnoth/developer/shadowmaster] has quit [Quit: food]
20100221 03:42:58< AI0867> mordante: is [window_definition] actually used anywhere?
20100221 03:52:28-!- MikeJB [~Michael@wesnoth/umc-dev/developer/aethaeryn] has joined #wesnoth-dev
20100221 04:07:18< CIA-88> ai0867 * r41313 /trunk/src/gui/auxiliary/window_builder/label.cpp: Initialize a variable with the boolean version of cfg["wrap"], not "wrap"
20100221 04:20:54-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20100221 04:36:14-!- Ivanovic_ [~ivanovic@dtmd-4db2a870.pool.mediaWays.net] has joined #wesnoth-dev
20100221 04:39:21-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has quit [Ping timeout: 245 seconds]
20100221 04:40:12-!- Ivanovic_ is now known as Ivanovic
20100221 04:42:34-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 71 bugs, 249 feature requests, 8 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100221 05:24:51-!- MikeJB [~Michael@wesnoth/umc-dev/developer/aethaeryn] has quit [Quit: quit()]
20100221 05:26:22-!- Espreon [~espreon@wesnoth/developer/espreon] has quit [Quit: WRYYYYYYYYYYYYYYYYYYYY!]
20100221 05:27:09-!- Blueblaze [~nick@adsl-99-158-47-180.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100221 05:40:35< CIA-88> ai0867 * r41314 /trunk/data/ (schema-gui.cfg tools/wmlvalidator): Expanded the gui schema a bit
20100221 05:43:44< CIA-88> ai0867 * r41315 /trunk/data/gui/default/window/formula_debugger.cfg: Move an attribute into the right tag, caught by wmlvalidator
20100221 05:44:07-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20100221 06:14:53-!- Blueblaze [~nick@adsl-99-158-47-180.dsl.hstntx.sbcglobal.net] has quit [Remote host closed the connection]
20100221 06:15:49-!- rolando [~rolando@150.116.108.93.rev.vodafone.pt] has quit [Quit: leaving]
20100221 06:16:25-!- relic [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20100221 06:16:26-!- relic is now known as Guest47341
20100221 06:17:02-!- Guest47341 [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Client Quit]
20100221 06:17:26-!- relic_ [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20100221 06:18:04-!- relic_ [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Client Quit]
20100221 06:18:14-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has joined #wesnoth-dev
20100221 06:20:26-!- [Relic] [~relic@99-58-54-211.lightspeed.milwwi.sbcglobal.net] has quit [Client Quit]
20100221 06:28:04-!- mjs-de [~mjs-de@vpw.wh.Uni-Dortmund.DE] has joined #wesnoth-dev
20100221 07:09:23-!- ancestral [~ancestral@97-116-104-150.mpls.qwest.net] has quit [Read error: Connection reset by peer]
20100221 07:09:38-!- ancestral [~ancestral@97-116-104-150.mpls.qwest.net] has joined #wesnoth-dev
20100221 07:10:33-!- dtiger [~dtiger@dynamic-vpdn-93-125-15-91.telecom.by] has joined #wesnoth-dev
20100221 07:40:54-!- Zarel [~Zarel@warzone2100/developer/Zarel] has quit [Ping timeout: 272 seconds]
20100221 08:35:41-!- Espreon [~espreon@wesnoth/developer/espreon] has quit [Remote host closed the connection]
20100221 08:39:42-!- zookeeper [~l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20100221 08:49:44-!- silene [~plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100221 08:52:56-!- mordante [~mordante@wesnoth/developer/mordante] has joined #wesnoth-dev
20100221 08:53:06< mordante> servus
20100221 08:57:42-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has quit [Quit: crimson_penguin]
20100221 09:04:39-!- k23z__ [~k23z__@188.26.49.63] has quit [Read error: Connection reset by peer]
20100221 09:12:28-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100221 09:14:39< CIA-88> zookeeper * r41316 /trunk/data/core/images/terrain/forest/ (pine-small-2.png pine-small.png snow-forest-small.png): Fixed a few forest tiles which weren't working well with adjacent encampments.
20100221 09:19:45< mordante> AI0867, yes window definitions are used they determine whether the window is solid or opaque
20100221 09:20:12< mordante> AI0867, nice to see your validator catches issues :-)
20100221 09:20:44< boucman> zookeeper: did you close the bug itself ?
20100221 09:21:12< zookeeper> boucman, no
20100221 09:21:59< boucman> isn't it fixed ?
20100221 09:23:28< zookeeper> see jetrel's comment
20100221 09:23:49< boucman> ok
20100221 09:29:52-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20100221 09:58:53< CIA-88> boucman * r41317 /branches/water_animation/src/ (builder.cpp builder.hpp): fix random start of animation not working for bigger than hex animations (windmills)
20100221 10:00:48-!- ilor [~user@wesnoth/developer/ilor] has joined #wesnoth-dev
20100221 10:01:30< CIA-88> boucman * r41318 /branches/water_animation/ (63 files in 5 dirs): made all animated terrain use the new macro system
20100221 10:07:54< mordante> boucman, you managed to do it?
20100221 10:08:08< boucman> yes
20100221 10:08:28< boucman> it was quite easy once I understood how it worked
20100221 10:08:45< mordante> ah cool
20100221 10:16:34-!- Ivanovic [~ivanovic@dtmd-4db2a870.pool.mediaWays.net] has quit [Changing host]
20100221 10:16:34-!- Ivanovic [~ivanovic@wesnoth/developer/ivanovic] has joined #wesnoth-dev
20100221 10:18:39< Ivanovic> moin
20100221 10:18:56< mordante> hi Ivanovic 
20100221 10:19:26< Ivanovic> have i missed much yesterday beside the map format/editor discussion that was also mirrored (partly) on the ML?
20100221 10:19:59< mordante> Ivanovic, partly best read the log
20100221 10:20:31< Ivanovic> too much to read!
20100221 10:20:41< Ivanovic> that is: yeah, i saw that shadowmaster asked for 1.7.14 asap
20100221 10:21:06< Ivanovic> for me it depends on the state of the lobby and the mp campaign stuff
20100221 10:21:34< Ivanovic> fendrin: i assume that this is seriously improved since .13, right? (considering the stuff yogihh submitted since then)
20100221 10:34:47-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100221 10:34:57-!- Blarumyrran [~Blarumyrr@81-20-159-197.levira.ee] has joined #wesnoth-dev
20100221 10:39:32< boucman> esr: around ?
20100221 10:44:35< mordante> Ivanovic, the lobby is still under some heavy coding, might be able to finish it today but not sure
20100221 10:44:58 * Ivanovic hopes you are able to fnish it today
20100221 10:45:02< mordante> but I think it would be nice to get a bit more testing before throwing it upon the users
20100221 10:47:54-!- silene [~plouf@wesnoth/developer/silene] has quit [Quit: Leaving.]
20100221 10:49:39< Ivanovic> esr, fendrin: could you please *specify* the "this is what the tool should be *in the end*" regarding the editor?
20100221 10:50:09< Ivanovic> the discussion i saw yesterday was mainly a "oh, it would be nice to have ABC, this really should be in the editor"
20100221 10:50:24< Ivanovic> later on followed by a "we could also add YXZ, it would make sense to have"
20100221 10:51:06< Ivanovic> personally i would love to see a list of *all* the stuff that you want in our "editor" (yes, i leave 'map' out of the name by purpose!)
20100221 10:51:17-!- Espreon [~espreon@wesnoth/developer/espreon] has quit [Quit: WRYYYYYYYYYYYYYYYYYYYY!]
20100221 10:52:04< Ivanovic> then we can add what the editor (the map editor) already has to do these days, since it is in fact more than mere "place tile at ABC"
20100221 10:53:09< Ivanovic> in those specifications for the editor i would love to also have "systems where it should run on" (cf the talk about resolutions yesterday)
20100221 10:53:43< Ivanovic> my target with those questions is to get one fixed basis that we can work with and discuss to find a well working solution for basically everyone of us
20100221 10:56:31-!- ancestral [~ancestral@97-116-104-150.mpls.qwest.net] has quit [Quit: ancestral]
20100221 11:27:45-!- silene1 [~plouf@ASte-Genev-Bois-152-1-60-185.w83-114.abo.wanadoo.fr] has joined #wesnoth-dev
20100221 11:27:54-!- silene1 is now known as silene
20100221 11:27:59-!- silene [~plouf@ASte-Genev-Bois-152-1-60-185.w83-114.abo.wanadoo.fr] has quit [Changing host]
20100221 11:27:59-!- silene [~plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100221 11:35:47-!- loonybot [~loonybot@ppp79-139-136-187.pppoe.spdop.ru] has joined #wesnoth-dev
20100221 11:35:47-!- loonybot [~loonybot@ppp79-139-136-187.pppoe.spdop.ru] has quit [Changing host]
20100221 11:35:47-!- loonybot [~loonybot@wesnoth/bot/loonybot] has joined #wesnoth-dev
20100221 11:36:37-!- loonycyborg [~sergey@wesnoth/developer/loonycyborg] has joined #wesnoth-dev
20100221 11:36:39-!- Appleman1234 [~Appleman1@CPE-124-191-176-143.oxqn1.cha.bigpond.net.au] has joined #wesnoth-dev
20100221 11:44:14< CIA-88> mordante * r41319 /trunk/src/gui/widgets/ (11 files): 
20100221 11:44:14< CIA-88> Make layout_children a virtual function.
20100221 11:44:14< CIA-88> This allows the window the call the routine shortly before updating the
20100221 11:44:14< CIA-88> dirty list. The tree view is the only widget that really uses it (the
20100221 11:44:14< CIA-88> others simply forward the call), but others will follow later.
20100221 11:44:17< CIA-88> mordante * r41320 /trunk/src/gui/widgets/ (stacked_widget.cpp stacked_widget.hpp): 
20100221 11:44:17< CIA-88> Implement layout_children().
20100221 11:44:17< CIA-88> It now properly forwards it to all children in the generator.
20100221 11:44:20< CIA-88> mordante * r41321 /trunk/src/gui/widgets/tree_view.cpp: Fix some comments.
20100221 11:52:11-!- Noyga [~noyga@wesnoth/developer/noyga] has joined #wesnoth-dev
20100221 12:05:42< CIA-88> mordante * r41322 /trunk/ (4 files in 2 dirs): 
20100221 12:05:42< CIA-88> Fixes empty rows in the MP game list.
20100221 12:05:42< CIA-88> Upon removal of games the listbox was not properly updated, the next
20100221 12:05:42< CIA-88> call to invalidate_layout() "fixed" the problem. Since the number of
20100221 12:05:42< CIA-88> calls to invalidate_layout() is getting lower the issue became more
20100221 12:05:42< CIA-88> apparent.
20100221 12:05:48< mordante> ilor, ^
20100221 12:06:05< ilor> mordante: nice
20100221 12:06:11< mordante> Ivanovic, ^^ that fix should fix one or the more important known issues
20100221 12:06:31< mordante> but I like to do more testing to see whether there are more regressions around or not
20100221 12:06:46< ilor> mordante: if the layout breakage after some time could be fixed, the lobby might be release-worthy finally
20100221 12:06:50< Ivanovic> mordante: cool!
20100221 12:07:55< mordante> ilor, jup, but first want to test a bit further to see whether I didn't introduce new regressions
20100221 12:08:10< ilor> mordante gooood.
20100221 12:08:10< boucman> mordante: are we in (1.7) releaseable state ?
20100221 12:08:32< mordante> ilor, I had some but that is in my very experimental checkout so want to test with one with less cruft
20100221 12:08:51< mordante> boucman, not yet and I want to test more
20100221 12:08:58< boucman> k
20100221 12:09:06< ilor> btw Ivanovic I answered your editor question on the ML
20100221 12:09:49< mordante> but it would be nice if some more people would test the lobby, I'm off for lunch now
20100221 12:10:08< mordante> well after I read ilor's email
20100221 12:12:09< boucman> ilor: thx for the summary, i needed it too
20100221 12:12:46-!- mjs-de [~mjs-de@vpw.wh.Uni-Dortmund.DE] has quit [Remote host closed the connection]
20100221 12:14:47-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100221 12:25:00-!- AnMaster [~AnMaster@unaffiliated/anmaster] has quit [Read error: Connection reset by peer]
20100221 12:30:29< Ivanovic> writing a reply
20100221 12:32:22-!- AnMaster [~AnMaster@unaffiliated/anmaster] has joined #wesnoth-dev
20100221 12:40:33-!- Appleman1234 [~Appleman1@CPE-124-191-176-143.oxqn1.cha.bigpond.net.au] has quit [Quit: Leaving]
20100221 12:40:59< Ivanovic> lenghty reply including a proposal for this stuff sent
20100221 12:44:20-!- grzywacz [~grzywacz@wesnoth/developer/grzywacz] has joined #wesnoth-dev
20100221 12:49:25-!- happygrue [~George@wesnoth/developer/wintermute] has joined #wesnoth-dev
20100221 12:49:45-!- zookeeper2 [~l@88-148-251-223.bb.dnainternet.fi] has joined #wesnoth-dev
20100221 12:50:09< CIA-88> ivanovic * r41323 /trunk/ (12 files in 11 dirs): 
20100221 12:50:09< CIA-88> updated Finnish translation
20100221 12:50:09< CIA-88> add some more finnish translators to the credits
20100221 12:50:48-!- Netsplit *.net <-> *.split quits: Noyga, zookeeper, happygrue_, isaac, lukjad86, Vetinari
20100221 12:54:20-!- Vetinari [~lukjad007@unaffiliated/lukjad007] has joined #wesnoth-dev
20100221 12:54:23-!- isaac [~isaac@debian/developer/isaac] has joined #wesnoth-dev
20100221 13:07:53-!- zookeeper2 is now known as zookeeper
20100221 13:08:02-!- zookeeper [~l@88-148-251-223.bb.dnainternet.fi] has quit [Changing host]
20100221 13:08:02-!- zookeeper [~l@wesnoth/developer/zookeeper] has joined #wesnoth-dev
20100221 13:13:29-!- lukjad86 [~lukjadOO7@unaffiliated/lukjad007] has joined #wesnoth-dev
20100221 13:16:52-!- silene [~plouf@wesnoth/developer/silene] has quit [Quit: Leaving.]
20100221 13:23:55< CIA-88> crab * r41324 /trunk/src/ai/actions.cpp: fix two bugs in ai action handling which lead to crashes if garbage arguments are passed to them
20100221 13:24:34< CIA-88> crab * r41325 /trunk/src/ai/game_info.hpp: add a missing typedef to ai game info
20100221 13:24:44< CIA-88> crab * r41326 /trunk/ (8 files in 5 dirs): Lua AI: redesign, simplified usage, added lua_ai test scenario
20100221 13:26:33< CIA-88> crab * r41327 /trunk/data/ai/dev/lua_ai.cfg: remove lua ai example from the list of MP ais, as now it can be tested from within test scenario
20100221 13:36:29< Crab_> Ivanovic: do you intend to release 1.7.14 today ?
20100221 13:41:37< fendrin> hi Crab_, mordante, Ivanovic
20100221 13:41:42< Crab_> hi fendrin
20100221 13:41:44< fendrin> hi ilor
20100221 13:41:50< ilor> hi fendrin
20100221 13:42:48< fendrin> Ivanovic: YogiHH fixed the serious bugs in the multiplayer campaign code yesterday. It is not heavily tested but seems to work. I call it a major improvement.
20100221 13:43:38< fendrin> Ivanovic: So from the multiplayer campaign point of view it would be good to have another beta soon.
20100221 13:44:37< fendrin> Ivanovic: The new editor features are all summarized on the dev-ml.
20100221 13:46:04< fendrin> Ivanovic: These are: settings of [label]. placement of [item], a named location that can be used instead of coordinates [named_location]?, sound sources and at a later point it should be able to place [units]
20100221 13:46:33-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100221 13:48:46-!- dtiger [~dtiger@dynamic-vpdn-93-125-15-91.telecom.by] has quit [Read error: Operation timed out]
20100221 13:48:53-!- stikonas [~and@bcm-131-111-247-5.girton.cam.ac.uk] has joined #wesnoth-dev
20100221 13:48:54-!- stikonas [~and@bcm-131-111-247-5.girton.cam.ac.uk] has quit [Changing host]
20100221 13:48:55-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100221 13:50:00-!- dtiger [~dtiger@dynamic-vpdn-93-125-15-91.telecom.by] has joined #wesnoth-dev
20100221 13:54:52< fendrin> Ivanovic: The mail ilor sent to the dev-ml is pretty much what I think as well and I guess it also confirms with esr's thoughts.
20100221 13:54:59< Crab_> Ivanovic: ok, I have to go now, will return later today. If you'll release 1.7.14 today, be sure to mention something like "almost a year passed after python ai was removed - and now, another way to script AI is available - we can now use Lua to write AIs" - as it works good enough now.
20100221 13:55:53< fendrin> Crab_: The have a file release notes that is exactly for that. Put your text in there and it will be part of it. 
20100221 13:56:01< fendrin> At least it worked for me last time.
20100221 13:56:46< Crab_> fendrin: ok, thanks
20100221 13:57:15< Ivanovic> that is the way things are supposed to work
20100221 13:58:02< Ivanovic> if you got some nice two or three sentences that should be pasted into the announcement, then add the stuff (in correct english if possible, normally i just copy&paste this part!) to RELEASE_NOTES and i will paste the content when announcing the release
20100221 13:58:25< Ivanovic> basically you got some more hours after tagging, since i use the latest trunk version as of "when writing the announcement"
20100221 13:58:28< ilor> more mails senst...
20100221 13:58:32< ilor> *sent
20100221 13:58:58< CIA-88> crab * r41328 /trunk/RELEASE_NOTES: added note about Lua AI to release notes
20100221 14:00:00-!- Crab_ [~Crab_@wesnoth/developer/crab] has quit [Quit: Leaving.]
20100221 14:04:13< Ivanovic> ilor: personally i *really* disagree about the unit stuff
20100221 14:04:33< Ivanovic> ilor: units should IMO be done like "wml features" as in just placing named locations and that's it
20100221 14:05:10< Ivanovic> maybe some specific "location namespace" or the likes (as in "different color for overlay" or whatever), but the unit stuff itself should *not* be directly in any map files
20100221 14:07:02< ilor> Ivanovic: I keep saying I'm not entirely convinced about the units about once every three paragraphs in my emails :P
20100221 14:07:22< Ivanovic> and you still spend most of your mail regarding what could be done with the units
20100221 14:07:24< Ivanovic> ;)
20100221 14:08:05< ilor> I have to be positive ;p
20100221 14:08:27< Ivanovic> another point in your mail:
20100221 14:08:31< ilor> what mordante posted about only allowing a small subset of [unit] sounds good though
20100221 14:09:19< Ivanovic> you basically say that it does not make much sense to split maps and "definitions that are more than just terrains" which could make things easier for reusing maps
20100221 14:09:42< Ivanovic> since the content designer can just "remove" things from existing maps by hand editing things in the scenario cfg file
20100221 14:09:49< ilor> Ivanovic: need to go afk for 5mins
20100221 14:09:59< Ivanovic> i thought this was *exactly* what we wanted to reduce, to change this stuff plainly by hand
20100221 14:12:09< Ivanovic> and like tsr wrote, a *really* simple map file (with just the terrains as comma/newline seperated list) makes things easy to use with other tools when wanted (eg posting maps in the forums via some strange extension that we once had)
20100221 14:14:48< ilor> Ivanovic: I'm not sure how common it is to have the same map for several scenarios
20100221 14:14:59< Ivanovic> it is probably rather seldom
20100221 14:15:38< ilor> Ivanovic: and whether the inconvenience for everyone is worth the benefit there
20100221 14:16:00< Ivanovic> personally i don't really think that it *is* an inconcenience
20100221 14:16:50< Ivanovic> basically those two files will never be touched by hand (at least they should not be!)
20100221 14:17:24< Ivanovic> and most content designers just start their "definition file" which will automatically create the map file, if they want a different map just reused, they say it then and are done
20100221 14:17:35< Ivanovic> so things could be transparent to content creators
20100221 14:18:33< ilor> Ivanovic: it's not transparent if it's an extra file to manage
20100221 14:19:05< Ivanovic> ilor: what is to be managed?
20100221 14:19:11< Ivanovic> the managing is done by the editor
20100221 14:19:22< ilor> the extra file
20100221 14:19:23< Ivanovic> when uploading everything in the dir is uploaded
20100221 14:19:35< ilor> (this is starting to look like who is the leader of China joke)
20100221 14:19:41< Ivanovic> (using the pbl file there is no way to say "include file a, b and c but not d")
20100221 14:19:55< Ivanovic> yes, there is one more file
20100221 14:20:12< ilor> and this file has to be connected to a map file
20100221 14:20:14< Ivanovic> currently you should create a tarball anyway when sending your content to the forums
20100221 14:20:17< ilor> but it's not a 1-1 connection
20100221 14:20:21< Ivanovic> yes, something that by default would be done
20100221 14:20:38< Ivanovic> the content creator creates the "definition file" which automatically creates a map file, too
20100221 14:20:55< ilor> so when opening a map you have to think and figure out which definition file to load
20100221 14:20:58< Ivanovic> if the creator wants to reuse an existing map, he has to specify it there
20100221 14:21:14< Ivanovic> yes, instead of "which map file should i load" you ask yourself "which definition file should i load"
20100221 14:21:26< ilor> but we can also load standalone map files
20100221 14:21:39< ilor> so we have to keep track of whether a definition file is loaded
20100221 14:21:39< Ivanovic> yes, and?
20100221 14:22:12< ilor> someone starts off with a map file, and wants to add a label to it. what happens then?
20100221 14:22:41< Ivanovic> the question box opens "do you want to create a definition file or load an existing definition?"
20100221 14:22:59< Ivanovic> in general the normal start should *NOT* be the map file
20100221 14:23:11< Ivanovic> in general the normal start should be the definition file which links the map file
20100221 14:23:41< Ivanovic> yeah, at the beginning the defintion file would just be a "the map is called ABC", so unless labels or something else are placed it would be a single line
20100221 14:26:17< ilor> I see how this could work (even though I still don't like the separation, but anyway)
20100221 14:26:39< ilor> the .map file would be as it is now, and a scenario could use map_data={foo.map} 
20100221 14:27:00< ilor> but there would also be a .def or something file there and a scenario could use that instead
20100221 14:27:15< Ivanovic> for example
20100221 14:27:46< Ivanovic> like i said, there are probably many ways to make this work nicely, but i'd say that we should *first* talk about "what we really want" before we get to the implementation level
20100221 14:28:02< Ivanovic> what we have so far is:
20100221 14:28:02< ilor> we keep getting down to teh implementation level all the time anyw
20100221 14:28:04< ilor> ay
20100221 14:28:33< Ivanovic> 1) we want a separation between hand edited and gui edited, a content designer should never have to edit gui edited files "by hand"
20100221 14:29:10< Ivanovic> this includes "making things easy" by not having to have the exact hex locations at hand but using "labels" to make things easier
20100221 14:29:27< Ivanovic> 2) we want to somehow be able to make "placing things" easier
20100221 14:30:02< ilor> afk again (it's this "food" thing, brb)
20100221 14:30:17< Ivanovic> in this context "things" includes static objects on maps as well as possible places where events happen somehow or the likes, things that are not part of the plain map letters
20100221 14:30:37< Ivanovic> (we want to keep the letter format for maps as it is, right?)
20100221 14:30:58< fendrin> Well, the designer opens the map file, the editor will only display the objects that are within the mapfile. If the designer opens a scenario file in the editor the objects that are defined in the scenario will be displayed.
20100221 14:31:26< Ivanovic> fendrin: "opening a scenario file" is *HELL*
20100221 14:31:37< fendrin> why?
20100221 14:31:54< Ivanovic> fendrin: then you have to deserialize all data and serialize it again at the end
20100221 14:32:04< Ivanovic> probably content designers want their order kept
20100221 14:32:27< Ivanovic> and "nothing" should be lost even though macros should of course be interpreted correctly
20100221 14:32:57< Ivanovic> basically the whole of the complexity that a "real" scenario editor has
20100221 14:33:45< fendrin> The editor will not read the entire scenario. It goes only after the [map] tag.
20100221 14:33:55< Ivanovic> personally i would vote for the editor that we include *not* being able to load a .cfg file at all
20100221 14:34:19< Ivanovic> yes, but what about writing things out again?
20100221 14:34:19< fendrin> Ivanovic: Note that the editor is already able to open scenario files.
20100221 14:34:28< Ivanovic> then we do have a mix of machine and hand edited stuff
20100221 14:34:38< fendrin> Ivanovic: It will only write to the [map] tag as well.
20100221 14:34:42< Ivanovic> personally i don't think that this is a good thing!
20100221 14:35:20< Ivanovic> yes, but to write things back you need to either just say "okay, append it to file"/"replace a part" or you have to deserialize and serialize it again
20100221 14:35:59< fendrin> As long as the extra handwritten wml is valid that won't go wrong.
20100221 14:36:23< Ivanovic> fendrin: personally i am all for a strict separation between hand written and tool created
20100221 14:36:32< Ivanovic> yes, separation in files, too
20100221 14:37:01< Ivanovic> that is: how to handle things if you got the (wesnoth) editor open with the map stuff included and also have a text editor open with the scenario file
20100221 14:37:02< fendrin> That is possible as well, the system is very flexible.
20100221 14:37:32< Ivanovic> and you work on both things at the same time
20100221 14:38:01< Ivanovic> placing some objects using the editor (only map stuff) and do some work on eg events (not map related at all!)
20100221 14:38:14< Ivanovic> then you save in one tool and later on in the other, which change is kept?
20100221 14:38:24< fendrin> Ivanovic: No, the scenario editor is already doing it right. I just look for [map] in whatever is opened by the editor. 
20100221 14:38:24 * zookeeper doesn't see why several scenarios sharing the same map file would be a problem
20100221 14:38:28< Ivanovic> how to make sure that you don't overwrite one version?
20100221 14:39:17< fendrin> zookeeper: In that case some part of the objects would be defined in the scenario file. And that may cause problems like Ivanovic just points out.
20100221 14:40:32< fendrin> Ivanovic: I see your point and it is valid. Because of that I would define the [map] tag in another file and include it. That is already working nicely because the editor already works this way.
20100221 14:40:40< Ivanovic> fendrin: in general i vote for a strict separation since it allows us to write more effective "automation tools" and yeah, we should add a warning "if you edit this file by hand you are likely to not have it load and work anymore" to the machine generated files
20100221 14:40:54< ilor> I think the map editor should only "open" a scenario file in that it will be forwarded to the map file
20100221 14:40:55< zookeeper> fendrin, "some part of the objects" == scenery?
20100221 14:41:07< zookeeper> (if the scenery needs to be different in the scenarios)
20100221 14:41:14< fendrin> zookeeper: correct.
20100221 14:41:22< ilor> which is what it does now (forget about embedded maps for now)
20100221 14:41:37< zookeeper> oh well, i don't see a problem. then they just do it in the scenario file or duplicate the map or whatever.
20100221 14:41:40< fendrin> zookeeper: objects may also be named locations, sound sources, labels, items, maybe even units.
20100221 14:42:40< fendrin> Let's point out what is possible without changing the current implementation of the editor:
20100221 14:44:00< fendrin> 1. The map file is embedded in the scenario. The editor will load the map_data attribute and look for a [map] tag in the same file. Here we allready have the problem that the editor writes into a human editable file. So no extra evil behaviour to the current implementation.
20100221 14:45:12 * Ivanovic votes for removing *existing* evil behaviour, too
20100221 14:45:13< Ivanovic> ;)
20100221 14:45:19< ilor> fendrin: this is evil
20100221 14:45:36< ilor> fendrin: don't even for a while think this is good ;P
20100221 14:46:08< fendrin> So why did you implement embeded maps?
20100221 14:46:18< Ivanovic> because it was there before
20100221 14:46:40< Ivanovic> it is an ancient leftover that we IMO should remove in the 1.9.x series (yeah, we are allowed to clean up old things!!!)
20100221 14:47:01< fendrin> Aggreed, let's remove that feature from the editor, I am fine with that.
20100221 14:47:27< fendrin> If we go that far let's define it that way:
20100221 14:48:08< fendrin> the map_data attribute is a subtag of [map]. And should always be in a seperate file.
20100221 14:48:11-!- silene [~plouf@wesnoth/developer/silene] has joined #wesnoth-dev
20100221 14:48:34< zookeeper> what is an ancient leftover?
20100221 14:48:57< fendrin> The bourdersize and the other attribute that I don't remember, which is currently part of the map_data string will become attributes of [map]
20100221 14:49:39< fendrin> zookeeper: scenario embedded maps.
20100221 14:50:01< zookeeper> what are those?
20100221 14:50:37< Ivanovic> zookeeper: like for example the test scenario
20100221 14:50:49< Ivanovic> the map itself is part of the scenario file
20100221 14:50:55< fendrin> Ivanovic: Or many mp maps work that way.
20100221 14:51:02< zookeeper> ok. don't remove that possibility.
20100221 14:51:17< Ivanovic> zookeeper: why?
20100221 14:51:35< zookeeper> because it's handy to be able to have a scenario be only one file
20100221 14:52:04< Ivanovic> zookeeper: the result is that you do have a mix of "hand edited" and "gui edited" which we said is not nice at all
20100221 14:52:35< Ivanovic> fendrin: yeah, basically what i proposed so far
20100221 14:53:15< Ivanovic> fendrin: though in my version you have the map_data itself as one file and the content of [map] (or however it is called) as some "definition file"
20100221 14:53:28< fendrin> Well, the solution tha I am coding on is very flexible and will allow all sort of combinations. That way zookeeper is still be able to have everything in one file. Ivanovic and ilor can have all map stuff extra in a seperate file. And I can have some of the stuff in the scenario and extra not scenario specific stuff in the mapfile. And the best is that I don't need to change the editor's implementation for that in any way.
20100221 14:53:56< fendrin> Ivanovic: That is also possible.
20100221 14:54:03< fendrin> Without extra coding.
20100221 14:55:20< fendrin> And I agree that machine written stuff shouldn't go in a human writable file.
20100221 14:55:33< zookeeper> besides, the editor's ability to open the map from or via a scenario file isn't an ancient leftover. it was implemented sometime in 1.3 i think, on my request :P
20100221 14:56:15< Ivanovic> i would love to eg have a .map and a .def file per scenario and those files should start with some huge "#disclaimer, this file is machine edited and will likely stop working if you change things by hand!"
20100221 14:56:40< Ivanovic> zookeeper: ehm, was this not possible in the 0.8.x days, too?
20100221 14:57:46< fendrin> Ivanovic: There is no problem with that. As I said the system is very flexible. We can do that for the use cases where it is cool and we can let zookeeper keep his one file thing. Maybe with a #disclaimer -- This is zookeeper's domain don't touch it at all. 
20100221 14:57:50< Ivanovic> http://svn.gna.org/viewcvs/wesnoth/tags/v0_8_5/data/scenario-test.cfg?rev=4118&dir_pagestart=150&view=markup
20100221 14:58:26< Ivanovic> as you see, in 0.8.5 there was already this "embedded maps are possible" thingie
20100221 14:58:52< fendrin> I want't to code the flexible way. It is most easy to implement since the code is in place and I don't need to mess with the editor. Every kind of wanted stuff is doable with it. If we see the need to restrict that later, fine no problem.
20100221 14:59:00< Ivanovic> IIRC it was just that mordante removed it with the map rewrite and it was added after someone complained it was missing...
20100221 14:59:01< Ivanovic> ;)
20100221 15:01:24< CIA-88> fendrin * r41329 /trunk/src/ (map_label.cpp map_label.hpp): 
20100221 15:01:24< CIA-88> Refactored the map_labels and related classes.
20100221 15:01:24< CIA-88> The drawable class now inherits from the container class.
20100221 15:01:24< CIA-88> No change in game behaviour.
20100221 15:06:02< Ivanovic> fendrin: personally i would like to ignore the "coding perspective" for the moment and first start with "what do we really want to have?"
20100221 15:06:47< Ivanovic> fendrin: sure, once we have a list of this we can have a look "what is there and should be reused" as well as "what is there and is *not* good, thus should not be used"
20100221 15:07:14< ilor> I agree with Ivanovic. "the code already does that" is not an important argument
20100221 15:07:53< mordante> I think the editor can open the .cfg file READ ONLY so it can find the .map and .def and other helper files are and only edit these files
20100221 15:08:18< Ivanovic> mordante: yes, makes sense to me
20100221 15:08:23< ilor> mordante: yeah, this is a slight extension of what it does now
20100221 15:10:04< fendrin> ilor: No, the argument is that I don't care about that part of the code. All I want to do is independent from that behind interfaces. I am going to code the features now, behind nice little interfaces how I learned at scoool. You can do in your domain before that interfaces whatever you want and design that at any time. I do have time now and I am going to code the features. All your concerns aren't very important to me because that is not my 
20100221 15:10:06< fendrin> part of code I want to alter.
20100221 15:11:07-!- Noyga [~noyga@wesnoth/developer/noyga] has joined #wesnoth-dev
20100221 15:12:48< ilor> fendrin: wait, what? I don't even know what are you really trying to implement now
20100221 15:13:02< fendrin> The discussion is slowing me down for ne reason. Because that decission isn't important at that time of the projects process. My interface is a config object and how I get this isn't realy important.
20100221 15:13:52< fendrin> I can get it with a one liner without changing the editor in any way else. From that one liner on all I do will be behind the config objects interface.
20100221 15:14:15< ilor> fendrin: it might be important if we decide to have two separate files and not change the .map format at all
20100221 15:14:17< fendrin> You can change the loading mechanism of the editor at any time to anything you want.
20100221 15:14:42< fendrin> ilor: Not for me. As I said that decission doesn't touch my work at all.
20100221 15:15:05-!- elias [~elias@allegro/developer/allefant] has joined #wesnoth-dev
20100221 15:15:10< fendrin> ilor: It is the map_data= attribute that I won't touch in any way. 
20100221 15:15:15< Ivanovic> afk, breakfast
20100221 15:15:21-!- Blarumyrran [~Blarumyrr@81-20-159-197.levira.ee] has quit [Ping timeout: 240 seconds]
20100221 15:16:14< mordante> fendrin, why not discuss it first it makes zero sense to code first and design afterwards :-/
20100221 15:16:20< fendrin> ilor: Independent from what the developers design how the files are handled and what belongs where do I need to read from a [map] tag. 
20100221 15:16:47< fendrin> mordante: Because I work behind an interface.
20100221 15:16:55< fendrin> We can talk about that interface.
20100221 15:17:22< fendrin> But I don't want to talk about what belongs in which file. That doesn't matter for me. It will all be before the interface.
20100221 15:17:25< mordante> what do you mean "I work behind an interface"?
20100221 15:18:22< fendrin> mordante: At some time no matter from where I will have a wml config object. This object is my interface. I don't care from which file it is from. 
20100221 15:18:45< ilor> fendrin: would be better if you told us what is it taht you're actually doing
20100221 15:19:57< fendrin> ilor: I implement the editor to read a [map] tag, and display [item] [sound_source], [label], [unit], [named_location] from it.
20100221 15:20:29< mordante> fendrin, what's the reason of all the commented out code in r41329 ?
20100221 15:21:18< fendrin> mordante: The need for a terrain_label container that is free of drawing code.
20100221 15:21:27< mordante> and which bug does it fix?
20100221 15:22:25< fendrin> mordante: None.
20100221 15:22:52< fendrin> It is a code cleanup.
20100221 15:23:56< fendrin> mordante: It is the same like the bugs that crab for example fixes: No support for lua in the ai. bug fixed today :-P
20100221 15:24:49< mordante> code cleanups are no bug fixes IMO 
20100221 15:27:36< fendrin> mordante: Okay, I will try to wrap it in #ifdef EXPERIMENTAL
20100221 15:36:18< Ivanovic> re
20100221 15:36:41< Ivanovic> my experience says that code cleanups make the code easier to read but tend to add some new bugs, too
20100221 15:36:53< Ivanovic> so those should not be done unless it is required to fix bugs arm
20100221 15:36:56< Ivanovic> s/arm/atm
20100221 15:37:24< Ivanovic> i would *really* hate to have to wait for a fix for a bug in some "cleaned up" code since this does block 1.8 in some ways
20100221 15:38:17< fendrin> Ivanovic: Right, it will be guarded by EXPERIMENTAL soon.
20100221 15:40:26< Ivanovic> fendrin: and what will happen once trunk is open for post 1.8.x development?
20100221 15:40:40< Ivanovic> will you then remove all the experimental parts from branches/1.8 ?
20100221 15:43:22< Ivanovic> yes, this "hidden branch" inside "about to be stabilized" trunk is IMO not the best thing to do
20100221 15:43:28< Ivanovic> in theory there are several things:
20100221 15:43:49< Ivanovic> 1) work in a branch of its own with the issues that come with that (difficulties at merging)
20100221 15:44:00< silene> fendrin: no, it is not exactly the same as crab's commits; you are modifying existing code, while crab isn't
20100221 15:44:19< Ivanovic> 2) put those changes back and instead directly help with the blocking points to make 1.8 be releasable *really* soon so that you can then implement the new stuff
20100221 15:44:47< Ivanovic> 3) make me move 1.8 into branches/ before the release of 1.8.0 (most likely this won't happen!)
20100221 15:46:19< fendrin> Ivanovic: I helped with the blocking points, please see my work with yogihh on the multiplayer campaign front. That was hard work for both of us.
20100221 15:46:24< Ivanovic> in theory '1' should not be too much of a problem if you are really working with things that do not touch the rest since then you should not have too many merge conflicts (everything that should change in trunk atm are bug fixes that you should be able to also merge into your branch easily removing possible merge conflicts)
20100221 15:46:35< Ivanovic> fendrin: yes, i saw this
20100221 15:47:51< fendrin> Ivanovic: Still I don't have much time left to spend on wesnoth before semester starts again. So 3 would be me favourite, and shadowmaster's as well. Please branch 1.9 away now. ilor and mordante will finish the lobby and it can be released. shadowmaster has time now like me and not later.
20100221 15:48:24< Ivanovic> fendrin: and almost everyone directly starts hacking on new features without much getting fixed in 1.8
20100221 15:48:29< Ivanovic> yeah, that *is* what will happen
20100221 15:48:43< Ivanovic> that is (partly) already happening right now, it will just get worse
20100221 15:48:54< fendrin> Ivanovic: I thought 1.8 is nearly ready and only the lobby part is still lacking?
20100221 15:48:58< Ivanovic> the reason then being "ah, why should i work on 1.8 and port the changes over again"
20100221 15:49:25< Ivanovic> the main delay so far was the lobby
20100221 15:49:42< Ivanovic> now plus the multiplayer campaign stuff which also should be fixed before 1.8 if possible
20100221 15:53:20< CIA-88> ivanovic * r41330 /trunk/ (6 files in 5 dirs): updated Lithuanian translation
20100221 15:53:53-!- esr [~chatzilla@71.162.243.5] has quit [Remote host closed the connection]
20100221 15:57:20-!- esr [~chatzilla@71.162.243.5] has joined #wesnoth-dev
20100221 15:57:39-!- esr [~chatzilla@71.162.243.5] has quit [Changing host]
20100221 15:57:39-!- esr [~chatzilla@wesnoth/developer/esr] has joined #wesnoth-dev
20100221 15:57:39-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20100221 16:02:22-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100221 16:02:33< ilor> okay I need to run, be back online in ~2-3 hrs
20100221 16:02:39< ilor> see you
20100221 16:02:47-!- ilor [~user@wesnoth/developer/ilor] has quit []
20100221 16:04:39< silene> Crab_: hopefully you will get to read that and fix the issues before Ivanovic decides to release, otherwise I will just disable your Lua AI code until after the release
20100221 16:05:26< silene> 1. you are not allowed to call functions that can raise an error (e.g. getfield, luaL_check, and so on) when C++ objects are in scope
20100221 16:06:33< silene> 2. going through {x,y} tables to pass coordinates just cause memory to be wasted and collection to happen more frequently; just pass coordinates separately
20100221 16:07:28< silene> 3. similarly, don't return a table in transform_ai_action since the fields are always the same; just return three values
20100221 16:09:06< silene> 4. you are calling luaW_pcall without testing the return value
20100221 16:09:25< silene> 5. why is _side a function?
20100221 16:09:38< silene> 6. these _functions are really ugly
20100221 16:10:03< silene> by the way, 1 and 4 are security issues, hence why i will disable the code
20100221 16:13:22< CIA-88> fendrin * r41331 /trunk/src/map_label.hpp: Fixed wrong visibility for clear_map()
20100221 16:19:38< loonycyborg> silene: That's why I thought using luabind is a good idea: to hide those gory details from unsuspecting coders :P
20100221 16:22:34< silene> loonycyborg: luabind wouldn't have helped there; the only way to accomodate unsuspecting coders would have been to embed lua inside wesnoth so that we could compile it ourselves with the proper flags
20100221 16:23:22< loonycyborg> It would handle return values from luaW_pcall transparently for sure..
20100221 16:24:04< silene> loonycyborg: what do you think the W in luaW means? this is not a lua function, it is a wesnoth function ;-)
20100221 16:26:35< loonycyborg> 1. is due to lua using longjmp, right?
20100221 16:26:52< silene> right
20100221 16:27:17< silene> that's why we should recompile it, so that it doesnt use longjmp
20100221 16:27:40-!- stikonas [~and@wesnoth/translator/stikonas] has quit [Remote host closed the connection]
20100221 16:28:17< loonycyborg> Does it already have an option for that or we would be required to hack it?
20100221 16:28:42< silene> loonycyborg: it does
20100221 16:29:17< loonycyborg> I wonder why it uses longjmp by default then..
20100221 16:29:54-!- stikonas [~and@bcm-131-111-247-5.girton.cam.ac.uk] has joined #wesnoth-dev
20100221 16:29:54-!- stikonas [~and@bcm-131-111-247-5.girton.cam.ac.uk] has quit [Changing host]
20100221 16:29:54-!- stikonas [~and@wesnoth/translator/stikonas] has joined #wesnoth-dev
20100221 16:30:15< silene> loonycyborg: because that's the only exception mechanism available in C
20100221 16:30:48< silene> the only thing to do is to recompile lua with a c++ compiler (no need to even set an option somewhere) and then lua will stop using longjmp
20100221 16:31:10< loonycyborg> Python/C api seems to some how do without longjmp.
20100221 16:33:39< silene> yes, but the handling is a lot more heavy; you have to manually check whether the python code thrown an exception
20100221 16:34:40< loonycyborg> Indeed. But boost.python abstracts that and also refcounting.
20100221 16:41:33< CIA-88> fendrin * r41332 /trunk/src/hotkeys.hpp: Added hotkey for the label editor tool. EXPERIMENTAL
20100221 16:41:51< AI0867> 09:19 < mordante> AI0867, yes window definitions are used they determine whether the window is solid or opaque <-- but where is it used in the code? grepping for window_definition yields nothing
20100221 16:42:48< CIA-88> fendrin * r41333 /trunk/src/hotkeys.cpp: Added EXPERIMENTAL code for the handling of the label editor tool hotkey.
20100221 16:44:26-!- rolando [~rolando@3.38.103.87.rev.vodafone.pt] has joined #wesnoth-dev
20100221 16:44:29< CIA-88> fendrin * r41334 /trunk/src/editor/action.cpp: editor_action_label class implemented.
20100221 16:46:30< CIA-88> fendrin * r41335 /trunk/src/editor/action.hpp: editor_action class for the label feature defined.
20100221 16:47:36< CIA-88> fendrin * r41336 /trunk/src/editor/mouse_action.hpp: mouse action class for the editor label tool defined.
20100221 16:50:18< CIA-88> fendrin * r41337 /trunk/src/editor/mouse_action.cpp: mouse action class for the editor label implemented.
20100221 16:59:34< mordante> fendrin, crab_ was finishing his work on the ai
20100221 17:00:31< fendrin> mordante: ?
20100221 17:01:13< mordante> "fendrin> mordante: It is the same like the bugs that crab for example fixes: No support for lua in the ai. bug fixed today :-P"
20100221 17:01:33< mordante> fendrin, and please read the dev-ml
20100221 17:02:03-!- Zarel [~Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20100221 17:02:22< boucman> back
20100221 17:02:56< mordante> and I agree with Ivanovic forking 1.9 is a really bad idea
20100221 17:03:11< mordante> AI0867, http://paste.debian.net/60785/
20100221 17:09:52< fendrin> mordante: mail sent.
20100221 17:11:27< mordante> fendrin, you only send it privately, please send it to the dev-ml as well
20100221 17:13:26< CIA-88> zookeeper * r41338 /trunk/data/core/images/terrain/forest/ (pine-sparse-small.png snow-forest-sparse-small.png): Fixed the small sparse pines not really being small and sparse.
20100221 17:13:44< boucman> hehe
20100221 17:13:51< boucman> zookeeper: I like your commit message :)
20100221 17:14:14< mordante> indeed a nice message
20100221 17:14:57< zookeeper> whatever you say
20100221 17:16:09< fendrin> mordante: mail sent
20100221 17:20:02< CIA-88> fendrin * r41339 /trunk/src/editor/editor_controller.cpp: Registered the label tool to the editor gui.
20100221 17:24:00< boucman> fendrin: please try not to break the feature freeze (that totally unrelated to the whole editor discussion) I know it's hard to keep not adding stuff with the long feature freeze, but still...
20100221 17:24:39-!- Blarumyrran [~Blarumyrr@81-20-159-197.levira.ee] has joined #wesnoth-dev
20100221 17:25:22< fendrin> boucman: Right, I am going to be very carefull to not do that. Every new code that I introduce is garded with the EXPERIMENTAL compile flag like the new teleport feature.
20100221 17:25:33< boucman> oh, ok
20100221 17:25:42< boucman> sorry about that, then
20100221 17:25:59< fendrin> boucman: No problem.
20100221 17:29:42< boucman> esr: around ?
20100221 17:33:00< fendrin> boucman: Another option for the [item] placement in the editor your mail inspired me to: Just make automatically a terrain for every image in scenery/item. That may very few work and a good improvement to the situation.
20100221 17:33:50< boucman> fendrin: we could add all these manually as overlays, I guess
20100221 17:34:11< mordante> fendrin, replied
20100221 17:35:39-!- Zarel_ [~Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20100221 17:35:40< fendrin> boucman: I thought that as well but what about user made stuff? We don't have much of these images in core. Most of the usage is with custom made terrain and there it is too user unfriendly. The UMC designer should be able to put it in toplevel_of_campaign/images/scenary   or items and that's it.
20100221 17:35:49< mordante> ilor still out-of-bounds errors http://paste.debian.net/60790/
20100221 17:50:45< fendrin> mordante: mail sent
20100221 17:51:57< stikonas> Ivanovic: Hi. In tutorial when playing either Konrad or Li'sar and clicking Unit Description on them *huge* portraits are shown. Is this considered a bug?
20100221 17:53:36-!- crimson_penguin [~ben@wesnoth/developer/crimsonpenguin] has joined #wesnoth-dev
20100221 17:58:35< Ivanovic> no idea
20100221 17:58:58< Ivanovic> show a screenshot and i can say if this is correct or not
20100221 17:58:59< Ivanovic> ;)
20100221 18:06:00< stikonas> Ivanovic: http://stikonas.homelinux.org/files/li'sar.png
20100221 18:07:38< Ivanovic> why i find much more disturbing is that for delfador there is no picture shown when trying to get a description...
20100221 18:08:25< stikonas> yeah, I noticed that too
20100221 18:08:51< stikonas> it seems that there are some more bugs here
20100221 18:09:58< CIA-88> fendrin * r41340 /trunk/data/themes/editor.cfg: 
20100221 18:09:58< CIA-88> EXPERIMENTAL only
20100221 18:09:58< CIA-88> Button defined for the editor label tool.
20100221 18:10:08-!- Mythological [Mythologic@77.28.126.198] has joined #wesnoth-dev
20100221 18:10:59< Ivanovic> stikonas: please file a but report regarding the missing delfador
20100221 18:11:12< Ivanovic> the other images are 400x400 and just displayed this way without scaling
20100221 18:11:16< Ivanovic> so this is probably correct
20100221 18:11:35< Ivanovic> no idea if using those 400x400 images is intentional since the other portraits we use in mainline just have 205x205
20100221 18:11:55< Ivanovic> maybe mordante knows something if there are differences between the message dialog codes and the stuff displayed in the ingame help
20100221 18:12:41< CIA-88> fendrin * r41341 /trunk/data/core/editor/hotkeys.cfg: EXPERIMENTAL hotkey defined for the label tool in the editor.
20100221 18:12:54< stikonas> Ivanovic: also, I want to ask about the sorting of units in the in-game help. In English they are sorted in alphabetical order. In Russian (all leters are non-ASCII) or Lithuanian (some letters are non-ASCII) the sorting is somewhat broken
20100221 18:13:14< Ivanovic> stikonas: file a bug report
20100221 18:13:23< Ivanovic> no idea what else to do and how it should work for you
20100221 18:13:27< stikonas> maybe it should be possible to sort as defined in LC_COLLATE
20100221 18:13:36< stikonas> ok, will do so
20100221 18:13:43< mordante> fendrin, can we get back to discussing things instead of keep committing?
20100221 18:14:35< mordante> stikonas, Ivanovic I've no idea about the help, but it should use the old smaller image
20100221 18:14:37< mordante> images*
20100221 18:14:58< Ivanovic> mordante: ehm, from what i see in httt there are only the 400x400 images
20100221 18:15:21< Ivanovic> so how can it use the old smaller images if they are not available?
20100221 18:15:36< Ivanovic> anyway, this is a minor cosmetic issue
20100221 18:15:42< mordante> blame the one who removed them ;-)
20100221 18:15:51< Ivanovic> (a lot) more important is the mp lobby
20100221 18:15:56< mordante> but we could scale the 400x400 down
20100221 18:16:03< fendrin> mordante: sure, what do you want to discuss?
20100221 18:16:19< Ivanovic> and the current discussion we got about the editor and where the current "hey, it is marked experimental anyway" line is going
20100221 18:16:52< Ivanovic> yes, i *do* fear that those parts that "should not be accessible normally" do cause some strange problems
20100221 18:17:36< Ivanovic> and yeah, if esr wants to tests stuff that is being developed in a branch, a 2nd checkout of just that branch might be required to make it convenient, maybe adding some build scripts for him so that he easily can use both versions
20100221 18:17:38< boucman> i'd rather have a 1.9 branch than an EXPERIMENTAL flag
20100221 18:17:48< boucman> and i'd rather have no 1.9 branch at all
20100221 18:18:07< Ivanovic> i'd rather have issues left in current trunk fixed
20100221 18:18:09< Ivanovic> ;)
20100221 18:18:26< mordante> fendrin, what we want with the editor and whether it should end up in the map editor or a separate editor
20100221 18:18:31< Ivanovic> but if there are some (time) constraints that allow you to work on your new features only now it should be done in a seperate branch
20100221 18:20:33< fendrin> I whish people would trust me enough so I could just do my work. Honestly, I will call for you boys if I need help. But today I would like to code the features. That experimental thing was introduced so that someone can test things without them going out of sync with trunk. I worked hard since it is there. And now it is questioned again? Why that? Please let me work. I have read all concerns and will value them carefully.
20100221 18:20:42< mordante> I also prefer we focus on getting 1.8 working and bugs fixed instead of working on new features
20100221 18:21:04< mordante> fendrin, it's not about trust it's about what do we want to do with the editor
20100221 18:21:31< mordante> fendrin, we have the rule that big changes should be discussed on the dev-ml before starting to implement them
20100221 18:22:10< fendrin> mordante: This is not a big thing it is a very small one. I don't want to do much. 
20100221 18:22:13< mordante> fendrin, and some developers have raised concerns about which way you want to go with the editor and instead of addressing them you start to work on those features
20100221 18:22:24< fendrin> In fact this is a very little change to everything.
20100221 18:22:44< fendrin> Every tag is already there.
20100221 18:22:51-!- fkhodkov [~fedor76@ppp-78-24-27-143-bras0.istra.ru] has quit [Read error: Connection reset by peer]
20100221 18:22:56< fendrin> The editor must not be changed. only extended.
20100221 18:23:02< mordante> fendrin, it's not a little change it's changing the map editor into something different
20100221 18:23:42< fendrin> mordante: How often do you work with the map editor? Can I see examples of your work, please?
20100221 18:23:45< loonycyborg> mordante: Where's the harm in what he does in experimetal code? If his changes end up unacceptable they could just be dropped :P
20100221 18:24:39< boucman> mordante, fendrin please cool down, it's not sucha big deal and things are heating up faster than either of you want...
20100221 18:25:13< loonycyborg> But IMHO extending map editor seems sane. It's better than having a separate scenario editor for sure..
20100221 18:27:10< fendrin> That depends on what we want to do. I could think of a scenario editor that embedds the map editor and interacts with it.
20100221 18:27:21< mordante> boucman, I'm just seriously pissed of that while we're discussing this issue, fendrin already starts to commit code to implement it
20100221 18:28:05< fendrin> mordante: I need to see what is able to do. There is no point in discussing code that I am not used to. Please give me the chance to experiment with the code. 
20100221 18:28:06< loonycyborg> fendrin: That would be more tolerable indeed.
20100221 18:28:55< fendrin> loonycyborg: But even that soluton would have the new features in the editor, and not in the scenario designer. They are too much map bound.
20100221 18:29:31< loonycyborg> Indeed. That's why I'm against *separate* scenario editor.
20100221 18:29:47< fendrin> loonycyborg: Or the ineraction between editor/scenario designer would be very very closely.
20100221 18:30:00< mordante> fendrin, for experimenting a separate branch is the best way to go
20100221 18:30:54< loonycyborg> mordante: Only if you're using git :P
20100221 18:30:59< fendrin> mordante: I have made the other experience. It was very hard work to merge them back. I can handle the EXPERIMENTAL better.
20100221 18:33:00< boucman> fendrin: are git branches easier to handle ?
20100221 18:33:52< fendrin> boucman: I don't know. Would like to switch to git since ages but never realy came into it. I will switch to git when wesnoth goes from svn to it :-)
20100221 18:34:25< boucman> fendrin: i don't think wesnoth will ever go to git (too complicated for non-techies) 
20100221 18:34:45< boucman> however, this might be the right time for you to take the plunge and use our git-svn gateway...
20100221 18:34:47< loonycyborg> boucman: I heard that they are. Though I need more first hand experience to be sure.
20100221 18:34:49< stikonas> nowadays git isn't much complicated then svn
20100221 18:35:05< boucman> stikonas: let's focus on the main point
20100221 18:35:26< esr> boucman: You were looking for me?
20100221 18:35:30< mordante> fendrin, you said you want to experiment before discussing whether to add it, when doing that in trunk it's hard to remove especially since you use a flag already used for something else
20100221 18:35:34< fendrin> The main point is that the EXPERIMENTAL thing was introduced by esr for exactly the case I am using it.
20100221 18:35:38< boucman> esr: yes, just a quicky
20100221 18:35:56< fendrin> If you force me into a branch I havely rely on esr merging all my stuff later.
20100221 18:35:59< boucman> data/core/terrain-graphics/tiles.cfg around line 87
20100221 18:36:18< boucman> there is a macro param named frac_value instead of prob in a meta-macro area
20100221 18:36:23< mordante> fendrin, no since you already have three features underneath it so if we want to remove this feature it will be hard to do
20100221 18:36:45< boucman> it's trivial to fix but since you do type checking i wanted to point it to you first in case there was something one of your tools missed there
20100221 18:36:51< fendrin> And I don't see the point of doing so. The EXPERIMENTAL is working well.
20100221 18:36:53< esr> EVERYBODY:  The real reason EXPERIMENTAL exists is because merging in Subversion *sucks*!
20100221 18:38:00< Ivanovic> esr: then use git-svn, merging is meant to be a lot better there!
20100221 18:38:00< loonycyborg> EXPERIMENTAL is better because other people are less likely to break the code here because they can see it.
20100221 18:38:15< loonycyborg> They won't look in branches.
20100221 18:38:26< esr> It's all very well to say that serious development should take place in branches, but we (and especially I) have had practical experience that this is not actually practical.
20100221 18:38:40< boucman> EXPERIMENTAL is a mess when multiple people want to use it, and has high chance of accidentally leaking code
20100221 18:38:48< boucman> it's an ugly hack for a real problem
20100221 18:38:56< Ivanovic> as boucman said
20100221 18:39:19< mordante> loonycyborg, that's an odd statement since those people also disable the EXPERIMENTAL flag
20100221 18:39:22< boucman> esr: I have no first hand exp with svn branches, so I assume you know what you're talking about
20100221 18:39:24< Ivanovic> if there is just one feature under experimental it is possible to "just" remove that, if there are >1 it gets a real mess
20100221 18:39:34< boucman> could we use git branches to alleviate the problem ?
20100221 18:39:39< esr> I am not saying this to take a side in a dispute.  EXPERIMENTAL is indeed an ugly hack.  The real fix is a 3G versio n control system.
20100221 18:39:42< Ivanovic> boucman: most likely yes
20100221 18:40:03< Ivanovic> that is: it should be possible via git-svn
20100221 18:40:05< loonycyborg> mordante: I'm not saying that it's foolproof, but it's better than branches in that respect.
20100221 18:40:21< boucman> ok, esr, fendrin: what do you think of moving EXPERIMENTAL into a git branch ?
20100221 18:40:36< esr> boucman: Branches in a system wit good merge capability is the correct solution - git, hg, or bzr.
20100221 18:40:51< boucman> fendrin ?
20100221 18:40:56-!- Crab_ [~Crab_@wesnoth/developer/crab] has joined #wesnoth-dev
20100221 18:41:06< esr> boucman: I think that's a fine idea.  We're moving the project to git now?
20100221 18:41:09< mordante> loonycyborg, I disagree with ifdefs the changes are high you only compile with that and don't test whether it breaks when compiling without
20100221 18:41:21< mordante> esr, no why?
20100221 18:41:30< fendrin> boucman: If the whole project moves to git I am with it.
20100221 18:41:37< Ivanovic> esr: no, we are not moving the whole project to git
20100221 18:41:40< esr> Well, I just heard "move it to a git branch".
20100221 18:41:41< Ivanovic> that is: not now at least
20100221 18:41:49< Ivanovic> but you can use branches with git-svn
20100221 18:42:02< boucman> fendrin: the whole project won't move before 1.8 that's for sure, and we need to fix that problem now... are you vetoing using svn-git ?
20100221 18:42:07< mordante> you can use git-svn branches, I use several of them
20100221 18:42:22< loonycyborg> Ivanovic: Now the question is whether it can merges them as good as git branches.
20100221 18:42:41< fendrin> boucman: I don't know anything about git and can't say if it will fix any of the problems that a svn branch can bring with.
20100221 18:42:43< esr> Ivanovic: I don'y trust such gatewaying tools much.  They're fine for one-off or infrequent versions but I'm very dubious about production use.  Besides...
20100221 18:42:44< Ivanovic> loonycyborg: the matter is that the one keeping the branch has to merge stuff from trunk over regulary
20100221 18:42:50< Ivanovic> then there are no huge problems
20100221 18:43:12< fendrin> boucman: I fear I will have the complexities of both tools but no gain at all.
20100221 18:43:46< Ivanovic> fendrin: the complexity of svn should basically be gone, you don't really see that there is svn below
20100221 18:43:53< esr> fendrin just uttered the key criticism - you can end up with the complexity of both tools for no actual gain.
20100221 18:44:17< esr> I have seen this happen on another of my projects.
20100221 18:44:30< Ivanovic> yes, it can happen, but it should not
20100221 18:44:37-!- ilor [~user@wesnoth/developer/ilor] has joined #wesnoth-dev
20100221 18:44:42< boucman> esr: and EXPERIMENTAL has a pricetag too
20100221 18:44:50< Ivanovic> IIRC mordante used git-svn branches for his first gui2 move
20100221 18:45:09< esr> boucman: I agree.  EXPERIMENTAL sucks.  It's just that svn merging sucks more...
20100221 18:45:28< boucman> esr: and git-merging ?
20100221 18:46:03< esr> boucman: Usually pretty painless - tgit's merge algorithms are more capable.
20100221 18:46:08< boucman> esr, fendrin: if we want to move to git (I personally don't care either way) we need to get more devs on the boat and test how it works on the things we want to improve with git
20100221 18:46:17< boucman> and branches is the #1 issue
20100221 18:46:43< Ivanovic> and we need to find a host offering git!
20100221 18:46:51< esr> Note: I'm not wedded to git, but I do think we should move to one of git/hg/bzr.
20100221 18:46:52< Ivanovic> not sure if gna does so these days...
20100221 18:47:37< boucman> esr, fendrin: I reiterate my question... maybe this would be a good time to move EXPERIMENTAL to a git-svn branch so we see how it goes
20100221 18:48:35< boucman> Ivanovic: it does http://savannah.gnu.org/forum/forum.php?forum_id=4906
20100221 18:48:37< loonycyborg> boucman: Probably that'll require as much work as originally was required to make experimental ifdefs/
20100221 18:48:39< esr> boucman: Our conclusion wouldn't scale up to true production use where multiple branches are routine., That's when gatewaying starts to flounder badly.
20100221 18:48:42< mordante> Ivanovic, can't remember, but I use branches a lot
20100221 18:48:52< fendrin> boucman: Without a master that will let my without backup.
20100221 18:49:02< Ivanovic> boucman: we are not at gnu.org but at gna.org
20100221 18:49:03< boucman> esr: the idea is that at that point we might move to git
20100221 18:49:15-!- fkhodkov [~fedor76@ppp-78-24-27-143-bras0.istra.ru] has joined #wesnoth-dev
20100221 18:49:19< boucman> Ivanovic: oops, my bad :P
20100221 18:49:59< boucman> fendrin: I didn't understand your last sentence
20100221 18:50:28< fendrin> boucman: a local git won't over my any recovery if my cigarette burns down the house.
20100221 18:50:45< boucman> oh, ok.
20100221 18:50:49< esr> Anyway, boucman, you were trying to ask about one of my macro changes.  It was a hack to make the argument typechecking work.  If you know how to make the meta-macro consistent, go right ahead.
20100221 18:50:50< fendrin> boucman: There is the need of a central master somewhere.
20100221 18:51:09< boucman> esr: i'll fix it in the water-animation branch, thx
20100221 18:51:27< esr> boucman: You're welcome.
20100221 18:51:36< ilor> fendrin: why not use a svn branch via git and merge it via git later?
20100221 18:51:41< Ivanovic> cf http://git.wiki.kernel.org/index.php/GitHosting
20100221 18:51:48< Ivanovic> gna is not listed :(
20100221 18:51:59< fendrin> ilor: Because I don't know anything about git.
20100221 18:52:11< boucman> yeah, I found a "won't do" on the feature request
20100221 18:52:24< esr> I think moving to git/bzr/hg is well justified if it avoids fenfrin and mordante having a territorial scrap.
20100221 18:52:47< fendrin> IT will take me more time to learn git and to transfer the EXPERIMENTAL and whatever than coding that little new feature that already there. 
20100221 18:53:58< loonycyborg> Even googlecode now provides hg in addition to svn, even though it tries to be as simple as possible :P
20100221 18:54:20< fendrin> Why don't we settle the issue of another tool that is not a map editor but a scenario designer for the features.
20100221 18:54:37< fendrin> That is the whole point of it. 
20100221 18:55:01< esr> I am opposed to this sploi for the reasons ilor and I have already laid out.
20100221 18:55:17< esr> s/sploi/split/
20100221 18:55:18< boucman> fendrin: because you want to work on it right now (which makes sense) and we would like to avoid experimental becoming a mess
20100221 18:55:47< boucman> and that discussion is not trivial and can't be solved quickly
20100221 18:55:54< fendrin> boucman: Okay, but let's first discuss the thing with the editor. If the editor will stay a map only tool there is no point for me to work on it.
20100221 18:56:01< boucman> let's focus on getting fendrin a way to work that won't be disruptive
20100221 18:56:11< loonycyborg> boucman: I don't think that it'll become more messy than a separate branch..
20100221 18:56:55< boucman> well, some of us do...
20100221 18:57:32< boucman> moreover fendrin's problem is pretty generic, most of us want to experiment with stuff but can't and we can't really start with dozens of people using experimental
20100221 18:57:39< fendrin> c++ is full of preprocessor stuff. It sucks . c++ deserves many fish for that. But EXPERIMENTAL is only one of this ugly things more? How will it bring back dinosaur mounted nazis on earth?
20100221 18:57:40< boucman> that way is the way to madness
20100221 18:58:19< mordante> esr, it's not about territorial, but about what we want with the editor
20100221 18:58:48< mordante> esr, and I think it's rude to push your work in while it's still under discussion, which way to go
20100221 18:58:52< loonycyborg> boucman: I'm not going to use EXPERIMENTAL for my experiments in any case.
20100221 18:59:00< fendrin> boucman: Yes, that is why we should fork a new development branch away. Most open source project do so. 
20100221 18:59:17< esr> But then we have the merge horror again.
20100221 18:59:36< boucman> ok, so what should we do...
20100221 18:59:45< mordante> esr, and IMO the proper way is to discuss and design before starting to hack the code
20100221 18:59:52< esr> This is really telling me we've reached the pint where Subversion is actively hurting us.
20100221 18:59:52< fendrin> esr: Not quite. If poeple would realy respect the feature frezze and only repair the lobby it is doable.
20100221 18:59:55< boucman> I still think git-svn is the way to go until 1.8 is out and we can do something more definitive about the problem
20100221 19:00:37< esr> fendrin: Are you willing to stop work on new features for a while?
20100221 19:00:43< loonycyborg> I think that we should let fendrin finish his work an then scrap experimental once changes from it are fully integrated.
20100221 19:00:49< loonycyborg> *and
20100221 19:01:24< boucman> fully integrated would be post 1.8, and we should avoid having EXPERIMENTAL in 1.8
20100221 19:01:44< fendrin> esr: No, I can't master all my time like I want. It's spring brake now. That is beyond my might.
20100221 19:01:44< mordante> I think not working on new features during the feature freeze is the best solution
20100221 19:01:55< esr> I avfee we should abolish EXPERIMENTAL.
20100221 19:02:12< esr> s/avfee/agree/
20100221 19:02:29< mordante> off to dinner
20100221 19:02:46< esr> But I see fendrin's problem.  The periodss when he has time to do intensive work aren't his to control.
20100221 19:02:48< boucman> i don't think blocking fendrin is the way to go, we need to find a way for him to work, and any other dev that want to work on
20100221 19:03:11< fendrin> yes please
20100221 19:03:14< Ivanovic> okay, just asked in #gna if they plan to "soon" offer git support
20100221 19:03:30< esr> Then it's time to move to git/bzr/hg.
20100221 19:03:31< Ivanovic> http://pastebin.com/m64c21878
20100221 19:03:34< fendrin> shadowmaster has the same problem.
20100221 19:04:28< esr> He've got to stop talking symptoms and attack the root of the problem: We've outgrown Subversion.
20100221 19:04:46< esr> I was expecting this, but not so soon.
20100221 19:04:50< Ivanovic> esr: but we can't really switch right now, this is something we can tackle once 1.8 is out
20100221 19:05:15< stikonas> and switching is not so easy
20100221 19:05:17< boucman> esr: i'd tend to agree, but we have a problem to solve pre 1.8 and moving to git pre 1.8 is impossible, so let's look at what we can do now
20100221 19:05:18< Ivanovic> esr: since it won't be a simple "ask gna to upgrade to 'different scm system'"
20100221 19:05:37< stikonas> switching can't be done without some planing beforehand 
20100221 19:05:51< boucman> esr: so, would the git over svn branch  solution seem workable to you ?
20100221 19:05:56< Ivanovic> the thing that we can do right now is using git-svn where the branches in git are basically branches in svn
20100221 19:06:21< Ivanovic> that should be possible to do, so in fact you would be working with the tree that svn has and later on rely on the merging mechanics from git
20100221 19:06:24< loonycyborg> boucman: I still don't see how experimental can interfere with other devs.
20100221 19:06:28< esr> As long as it's just a temporary expedient, with a plan to move to full git ASAP.
20100221 19:07:28< esr> But I fear problems we're not anticipating if we have to do git-svn for more than 60-90 days.
20100221 19:07:42< boucman> loonycyborg: trust me, I had to handle ifdef mess in other projects... there is a reason why wesnoth use them as little as possible
20100221 19:07:43< fendrin> What loonycyborg says. We can stay with EXPERIMENTAL unitl 1.9 and move to git.
20100221 19:07:48< Ivanovic> once 1.8 is rolled out we can concentrate on planning the move to a new version system
20100221 19:08:08< Ivanovic> fendrin: we are having the problem that EXPERIMENTAL can easily lead to problems right now
20100221 19:08:30< Ivanovic> it is a rather fragile thing that can leak
20100221 19:08:33< esr> And now I have to go to lunch.  I think the group's focus is on the right problem now.
20100221 19:08:46< esr> Back in a few hours.
20100221 19:08:56< Ivanovic> and yes, i would prefer to be sure that we don't have such a leak for 1.8
20100221 19:10:32< fendrin> so no real solution in sight?
20100221 19:10:42< loonycyborg> boucman: ifdefs can indeed cause problems, but in this case those mostly will be for fendrin, not other devs.
20100221 19:11:06< boucman> loonycyborg: don't assume fendrin will be the only one using them
20100221 19:11:10< loonycyborg> Beside leaks that Ivanovic mentioned.
20100221 19:11:18< loonycyborg> boucman: Why?
20100221 19:11:29< loonycyborg> I for one won't be using it.
20100221 19:11:42< boucman> because at least shadowmaster seems to want to do some stuff, and I would like to try stuff too
20100221 19:12:28< loonycyborg> Well then don't do it you both :P
20100221 19:13:21< fendrin> boucman: Then let's fork a pre 1.9 branch together and keep it in sync with the fixes from trunk. If we do well it can get 1.9 later. If not we can fork the 1.8 and merge the patches.
20100221 19:14:29< boucman> fendrin: if you're ready to deal with svn branches, why not... but I thought the point was to avoid that...
20100221 19:15:15< fendrin> boucman: I am fine with everyone working his new features in one branch. And only bug fixing in a soon to be released one.
20100221 19:16:16< fendrin> boucman: it's just pointless to have a branch on my own that I can't sync with trunk alone. 
20100221 19:16:26< loonycyborg> The point here that if you're against experimental you should have slapped esr with a fish before he made it..
20100221 19:16:41< fendrin> And trunk is moving much heavier than you would expect for a feature frezze right now.
20100221 19:17:02< boucman> fendrin: I know :/
20100221 19:17:41< fendrin> I guess we can stay with betas for the next two month easily. 
20100221 19:19:14< fendrin> There will be more issues in the multiplayer system.
20100221 19:19:17< ilor> fendrin: BTW re your commits you left out bof sync comments from the starting position code in several places
20100221 19:19:51< fendrin> ilor: What are out of sync comments?
20100221 19:20:20< ilor> fendrin: comments about starting positions in label tools/actions
20100221 19:21:46< fendrin> ilor: Can you give me a line and a filename?
20100221 19:23:35< ilor> oh wait that's just a commented out copy of starting positions action code in action.cpp
20100221 19:25:39< fendrin> ilor: I will remove all commented out code soon (hopefuly) ...
20100221 19:26:42< ilor> fendrin: okay
20100221 19:27:04< fendrin> Okay now. stop working or keep commiting?
20100221 19:28:38< boucman> fendrin: you sure you don't want to try git-svn 
20100221 19:28:39< boucman> ?
20100221 19:28:50< boucman> that's the best we have to offer at this point
20100221 19:28:54< ilor> I'm off again, be back tomorrow I guess
20100221 19:29:28< Ivanovic> fendrin: http://www.dmo.ca/blog/20070608113513/
20100221 19:29:47< loonycyborg> I did checkout other wesnoth branches from git svn, and that was easy.
20100221 19:30:00< loonycyborg> But I didn't try to merge anything.
20100221 19:30:18< ilor> Ivanovic: git clone will take a day, someone better give fendrin the link to the repo tarball
20100221 19:30:21< Ivanovic> that sounds like a usable way to get several "real" svn branches into a git rep
20100221 19:30:24< loonycyborg> So I have no idea how easy that will be..
20100221 19:30:43< Ivanovic> loonycyborg: regarding the post "rather easy"
20100221 19:33:13< Ivanovic> ilor: no idea how to best use branches with git and what to clone, this just sounds like a usable solution
20100221 19:36:03< loonycyborg> E.g. everything I had to do to get the pathfind branch was 'git checkout git checkout fendrin_pathfind'
20100221 19:36:22< loonycyborg> scratch first 'git checkout'
20100221 19:38:39< Crab_> loonycyborg: afair, it might also be needed to do a git fetch  , to allow the remote branch start point to be fetched (e.g. git svn rebase only gets commits related to current branch) 
20100221 19:38:49< loonycyborg> Indeed.
20100221 19:40:41-!- ilor [~user@wesnoth/developer/ilor] has quit []
20100221 19:40:46< loonycyborg> All this nice stuff is paid in time spent on git svn fetch when getting all those branches.
20100221 19:41:10< fendrin> boucman: It was hard work to port all my stuff into EXPERIMENTAL. And now that was all for nothing? 
20100221 19:41:40< boucman> fendrin: sorry about that...
20100221 19:41:41< fendrin> I realy feel kicked up the arse. 
20100221 19:42:09< boucman> fendrin: we're trying to find a compromise that satisfies everyone and allows us to move to git eventually
20100221 19:42:34-!- Blueblaze [~nick@adsl-99-158-47-180.dsl.hstntx.sbcglobal.net] has joined #wesnoth-dev
20100221 19:42:42< boucman> the EXPERIMENTAL was created pretty fast, I personally havn't heard of it before it was created, or I would have voiced  against
20100221 19:43:15< loonycyborg> Then probably you're alone in that :P
20100221 19:43:19< Zarel_> You know what I find great about Warzone code?
20100221 19:43:25< Zarel_> http://pastebin.ca/1804869
20100221 19:43:37< loonycyborg> Even mordante seems more concerned with editor issues..
20100221 19:43:39< Zarel_> "If we're not at full HP yet, we're going to need some more indentation to do it!"
20100221 19:43:47< boucman> loonycyborg: that's not true, multiple persons have voiced concerns in this very discussion
20100221 19:44:21< Crab_> wesbot: log 40867
20100221 19:44:22< wesbot> esr * r40867 : Add experimental option.  This defaults to 'yes' for odd-numbered(unstable) versions, 'no' for even-numbered (unstable) versions.It controls an EXPERIMENTAL preprocessor symbol, defined onlywhen experimental is 'yes', and an EXPERIMENTAL automake conditional.Thio is meant as a guard option for experimental, developer-only code that should be disabled in stable versions.  The immediateapplication is fendrin's new pathfinding/tu
20100221 19:44:29< wesbot> URL: http://svn.gna.org/viewcvs/wesnoth?view=rev&rev=40867
20100221 19:44:40< Crab_> it appeared almost a month ago
20100221 19:45:50< mordante> boucman, I also raised concerns, but they were ignored
20100221 19:46:34< mordante> loonycyborg, I'm concerned about the fact that we have some rules and that people keep ignoring them even when told that they ignore them
20100221 19:47:11< mordante> and to be honest I don't think we've outgrown SVN, the real problem is keep developing while in feature freeze
20100221 19:47:25< loonycyborg> Indeed.
20100221 19:48:12< mordante> it would have been easy to fork 1.9 and have two branches to work on
20100221 19:49:09< boucman> let's not ramble about the past
20100221 19:49:15< mordante> ?
20100221 19:49:18< boucman> do we all agree on what to do next ?
20100221 19:51:29< mordante> sorry, I'm not sure what you mean?
20100221 19:51:35< fendrin> boucman: No, sorry no idea.
20100221 19:51:41< boucman> no big deal, never mind
20100221 19:52:06< boucman> moving to git-svn until we can move to git was the general idea
20100221 19:54:05< mordante> I really wonder why the usage of SVN is suddenly the problem :-/
20100221 19:54:17< boucman> fendrin: if you don't like that, that's fine, but please say so
20100221 19:54:34< boucman> mordante: because svn branches arn't pratically usable
20100221 19:54:52< loonycyborg> There's svnmerge..
20100221 19:55:00< fendrin> boucman: The move to git is fine for me.
20100221 19:56:28< mordante> boucman, to be honest, like I said before I don't think that's the real problem, the real problem is that we want to do new features while trying to get a stable version out
20100221 19:59:38< fendrin> boucman: But let's do it right and not with a gateway.
20100221 19:59:54< boucman> fendrin: we can't until 1.8 is out
20100221 20:00:22< AI0867> mordante: yes, twindow_definition exists, but I don't see the config "window_definition" used anywhere
20100221 20:02:32-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20100221 20:03:14< mordante> AI0867, which line?
20100221 20:03:24< mordante> nevermind, misread
20100221 20:04:44< boucman> ok, I have to go for now see you all later
20100221 20:05:31< mordante> bye boucman 
20100221 20:09:27-!- Zarel [~Zarel@warzone2100/developer/Zarel] has quit [Quit: This computer has gone to sleep]
20100221 20:15:15-!- Zarel_ [~Zarel@warzone2100/developer/Zarel] has quit [Ping timeout: 256 seconds]
20100221 20:15:45< mordante> AI0867, gui/widgets/settings.cpp:287 the load_definitions changes "window" to "window_definition"
20100221 20:19:05< Crab_> silene: a question about  "6.these _functions are really ugly" comment - how it'll be better to solve cause of this issue, "some functions in ai: are from wesnoth core, and some might come from UMC ,how to avoid potential name clashes?"
20100221 20:19:16< Crab_> silene:  just live with it and publish a list of new reserved names with each release ? or move 'core' functions to a separate helper object ? or ask UMC creators to stick to some naming policy ?
20100221 20:21:22< mordante> Ivanovic, the lobby still seems to have glitches and I'm not in the mood to work on them
20100221 20:21:45-!- fendrin [~fabi@88-134-102-127-dynip.superkabel.de] has joined #wesnoth-dev
20100221 20:21:45-!- fendrin [~fabi@88-134-102-127-dynip.superkabel.de] has quit [Changing host]
20100221 20:21:45-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100221 20:28:23-!- EdB [~EdB@tss37-1-89-84-18-220.dsl.club-internet.fr] has joined #wesnoth-dev
20100221 20:29:58< CIA-88> fendrin * r41342 /branches/fendrin_editor/: Initial branching for the work on the editor.
20100221 20:35:04< silene> Crab_: i don't understand why you put the engine function inside a user object; if they hadn't been there, there would be no potential conflict
20100221 20:39:45< Crab_> silene: I was thinking about 'maybe, later I'll ensure that the user will be able to override/replace/wrap a engine/core function with his own implementation, so, I'll put those engine/core functions inside the same table as the user functions use'. 
20100221 20:41:15< fendrin> Ivanovic: What was the cmake parameter for eclipse with debug and experimental again?
20100221 20:41:23< Crab_> silene: so, yes, I can get rid of '_' by placing all those engine/core functions in that 'data' external object which is accessible to user code (and rename it to a more proper name).
20100221 20:43:39< Ivanovic> fendrin: just generate things and then open it with cmake-gui or ccmake to generate new files
20100221 20:43:40< silene> why does it have to be an object? why not a simple table shared by all the ais?
20100221 20:44:11-!- shadowm_laptop [~ignacio@wesnoth/developer/shadowmaster] has joined #wesnoth-dev
20100221 20:44:39< Ivanovic> fendrin: in theory it should be a case of -DPARAM_NAME=true (setting for PARAM_NAME what you want to specify)
20100221 20:45:03< Ivanovic> but since you are most likely not scripting things you can just call ccmake after calling cmake and change things the way you want them
20100221 20:46:18< shadowmaster> I think cmake's way to specify configuration options is strange and not friendly for regular users
20100221 20:46:42< Ivanovic> shadowmaster: the normal way is to use cmake-gui for "end users"
20100221 20:46:50< shadowmaster> which is not installed by default
20100221 20:46:53< Ivanovic> if you want to script it is like for a compiler
20100221 20:47:14< Ivanovic> ccmake should be installed by default
20100221 20:47:38< shadowmaster> not in Debian Squeeze (it was in Lenny though IIRC)
20100221 20:47:58< shadowmaster> (I could be remembering openSUSE 10.3 instead...)
20100221 20:49:02< Ivanovic> then complain to the distros packagers
20100221 20:49:20< Ivanovic> since cmake itself does come with the tools to configure things, be it the gui or the commandline tool
20100221 20:51:14< shadowmaster> :<
20100221 20:52:23< fendrin> shadowmaster: I just use it for eclipse. Scons support would be fine as well.
20100221 20:56:03< Crab_> silene: well, I need (1) a table to hold persistent state for the ai and  (2) a table which will contain functions specific to current side, such as 'move','attack','possible_moves'. 
20100221 20:56:04< Crab_> silene: currently, I use wesnoth.require to return a table which contains an init function which, when called, will create (2) as a table of functions  which use (1) as an upvalue.
20100221 20:56:20< Crab_> silene: it can be done in a simpler way ?
20100221 20:58:18< Crab_> 'move' by side 1 means different thing than 'move' by side 2 (for they have different upvalue). so, as I understand (I might be wrong), I need to init a  separate table for each ai (but using wesnoth.require to avoid multiple recompilations of the same functions)
20100221 21:00:54< silene> Crab_: i still don't understand why the side number is not known by the engine; can you give me even one case where an action done by an ai will be preformed by a side different from the current one, and how it does not cause oos and things like that
20100221 21:01:01-!- Blarumyrran [~Blarumyrr@81-20-159-197.levira.ee] has quit [Ping timeout: 245 seconds]
20100221 21:02:30-!- Zarel [~Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20100221 21:03:31< Crab_> potential things like ai coordination with each other. somthing like:  'ai 1' asks 'ai 2' to evaluate a function (say, 'orcish chief' ai asks 'orcish sovereign' ai to  'give me a list of targets')
20100221 21:05:42< Crab_> silene: 'actions' of ais on 'not its turn' will surely cause OOS. but evalutions/chat messages won't cause OOSes.
20100221 21:07:33< silene> Crab_: how does this evaluation happens? how does an ai ask another one for an evaluation?
20100221 21:14:36< Crab_> this is not possible today, but I was thinking about adding a function which'll allow one of the ais to call a function from another.  this function will do an evaluation 'in context' of another ai, out of turn. it will also be very useful for humans to ask the things from the specific ai via console'
20100221 21:15:51< zookeeper> stikonas, Ivanovic, mordante, there's no need for konrad's and li'sar's unit types to even have portraits in the first place.
20100221 21:16:19< zookeeper> those should just be konrad and li'sar's own portraits instead
20100221 21:17:04< stikonas> zookeeper: have you seen this: http://stikonas.homelinux.org/files/li'sar.png
20100221 21:17:20< zookeeper> stikonas, i have now
20100221 21:17:30< silene> Crab_: don't concern yourself with an issue that doesn't currently exist and that will perhaps not even exist later; make a simple interface for what currently exists
20100221 21:17:32< zookeeper> that's what your bug report was about
20100221 21:17:42< fendrin> Ivanovic: The gui doesn't help me. cmake-gui doesn't know about EXPERIMENTAL.
20100221 21:18:03< Ivanovic> fendrin: uhm, it should if you go to the extended options
20100221 21:18:12< Ivanovic> probably it is just EXPERIMENTAL anyway
20100221 21:19:29-!- Blarumyrran [~Blarumyrr@81-20-159-197.levira.ee] has joined #wesnoth-dev
20100221 21:21:58-!- Vetinari_ [~lukjad007@unaffiliated/lukjad007] has joined #wesnoth-dev
20100221 21:22:58-!- elias [~elias@allegro/developer/allefant] has quit [Quit: Leaving]
20100221 21:23:27-!- lukjad007 [~lukjadOO7@unaffiliated/lukjad007] has joined #wesnoth-dev
20100221 21:23:47< Crab_> silene: ok
20100221 21:24:54-!- Vetinari [~lukjad007@unaffiliated/lukjad007] has quit [Ping timeout: 252 seconds]
20100221 21:25:10< Crab_> silene:  then, next question. about "2. going through {x,y} tables to pass coordinates just cause memory to be wasted and collection to happen more frequently; just pass coordinates separately"
20100221 21:25:11< Crab_> silene:  what do you think about allowing both {x=,y=} tables to be passed as well as coordinates ? to allow to write things like ai:move(my_leader,13,22}) instead of ai:move(my_leader.x,my_leader.y,13,22})
20100221 21:26:05< Crab_> as there's a large number of cases where that {x=,y=} table comes from a table representing a unit, where x=,y= are already grouped together.
20100221 21:26:13-!- lukjad86 [~lukjadOO7@unaffiliated/lukjad007] has quit [Ping timeout: 264 seconds]
20100221 21:27:41< silene> Crab_: units are not represented by tables; i don't mind the function noticing that a unit is passed as a first parameter and recovering the coordinates from it; but i mind the function allowing {x,y} tables, since it is neither uniform with the other functions nor efficient
20100221 21:29:48-!- Blarumyrran [~Blarumyrr@81-20-159-197.levira.ee] has quit [Quit: Lahkun]
20100221 21:29:52-!- noy [~Noy@wesnoth/developer/noy] has joined #wesnoth-dev
20100221 21:30:09-!- shadowm_laptop [~ignacio@wesnoth/developer/shadowmaster] has quit [Ping timeout: 260 seconds]
20100221 21:31:33< Crab_> silene: ok, I'll allow units to be passed instead of a pair of coordinates, but will disallow tables.
20100221 21:32:04< Crab_> silene: I see how it's done (e.g. in intf_find_path)
20100221 21:33:42-!- lukjad007 is now known as lukjad86
20100221 21:34:06< Crab_> silene: about 'similarly, don't return a table in transform_ai_action since the fields are always the same; just return three values' - 
20100221 21:34:24< Crab_> silene: I'm thinking about returning a 1 userdata object representing the action result (that's because different actions have different outcomes - e.g. move action result allows to get the 'ambusher' unit if there was ambush. what do you think about that approach ?
20100221 21:35:07< Crab_> silene: and it doesnt' make sense to transform optional things like 'a list of seen enemies' to lua if it's not requested by the user
20100221 21:35:49-!- Noyga [~noyga@wesnoth/developer/noyga] has left #wesnoth-dev ["Quitte"]
20100221 21:37:15< mordante> I'm off bye
20100221 21:37:30-!- mordante [~mordante@wesnoth/developer/mordante] has quit [Quit: Leaving]
20100221 21:39:38< silene> Crab_: hmm... i've mixed feelings on this; if you return a userdata, it means that there is an underlying object which contains all the data (e.g. the list of seen enemies) and this object will possibly be kept alive for a long time; on the other hand, if these are heavy data, it indeed makes sense to have a userdata for them; what about adding a parameter to the function which tells if the user is interested in these additional data?
20100221 21:42:47-!- Zarel [~Zarel@warzone2100/developer/Zarel] has quit [Quit: This computer has gone to sleep]
20100221 21:43:33< Crab_> silene: well, the problem is that we usually don't know if we're interested in that data before the action happens. e.g. we're only interested in ambusher location if the return code is E_AMBUSHED, we're only interested in failed teleport location if we got E_FAILED_TELEPORT, etc..
20100221 21:44:32-!- dtiger [~dtiger@dynamic-vpdn-93-125-15-91.telecom.by] has quit [Remote host closed the connection]
20100221 21:44:42< Crab_> and, there's an underlying object which contains all the data, but there's no reason to keep it alive for a long time
20100221 21:45:54< silene> Crab_: ??? obviously the coder knows whether he will need the ambusher location or not; it's written in the code!
20100221 21:46:29< silene> Crab_: i don't follow, the underlying object has to be kept alive for as long as the userdata
20100221 21:48:43< Crab_> silene: " obviously the coder knows whether he will need the ambusher location or not;" - not in all cases, the coder can only know 'I might need the location of the ambusher, I have code which checks for that', but the coder cannot actually know if there'll be ambush or not. and ambushes are rare enough.
20100221 21:49:19< silene> Crab_: there is no ambusher location if there is no ambush!
20100221 21:49:27< Crab_> yes
20100221 21:50:46< silene> either the code needs the ambusher location or it doesn't (in case of an ambush); the decision doesn't depend on whether there was an ambush or not
20100221 21:52:05< Chusslove> Ivanovic: There?
20100221 21:52:10< Ivanovic> yes
20100221 21:53:00< Chusslove> Ivanovic: There are currently sr and sr@latin translations for Serbian. Would it be a problem if two more @... variants would come? (I've an interested party to work on them.)
20100221 21:53:20< Ivanovic> uhm, i don't think this would be a problem
20100221 21:53:31< Chusslove> They don't have to be added these days, but say in a month or so.
20100221 21:53:33< Chusslove> Great.
20100221 21:55:09-!- rolando [~rolando@3.38.103.87.rev.vodafone.pt] has quit [Ping timeout: 252 seconds]
20100221 21:55:28-!- rolando [~rolando@3.38.103.87.rev.vodafone.pt] has joined #wesnoth-dev
20100221 21:57:03< stikonas> Chusslove: do you know why are units listed in alphabetical order in the in-game help if I use sr locale? They are not sorted correctly of I use ru or lt locale.
20100221 21:57:30< Crab_> silene: ok, we were using a slightly different definition of 'needs'. let's return to the original question. we have http://wesnoth.pastebin.com/m58a7f131 in move_unit_spectator class.
20100221 21:57:36-!- Blueblaze [~nick@adsl-99-158-47-180.dsl.hstntx.sbcglobal.net] has quit [Ping timeout: 252 seconds]
20100221 21:57:53< stikonas> Chusslove: both sr and ru used cyrillic characters, so it is strange that one language is sorted correctly while the other isn't
20100221 21:57:59< Chusslove> stikonas: No idea :) In which way are they not sorted correctly?
20100221 21:58:21< stikonas> they are not in alphabetical order
20100221 21:58:23< Chusslove> Theoretically, could be collation order messed up in the libc locale, but probably unlikely.
20100221 21:58:33< Crab_> silene: is 'use one optional parameter if we need this extra info' a good solution ? or should it be multiple optional parameters ? or should it be dealt with as userdata ?
20100221 21:59:09< stikonas> Chusslove: this is unlikely colltation order bug, more likely, that wesnoth ignores collation rules
20100221 21:59:32< Chusslove> But then really why ok for sr, not ok for ru?
20100221 21:59:47< Chusslove> In fact, if it would use pure Unicode collation, than ru would be fine, and sr not.
20100221 21:59:47< stikonas> I can  post screenshot for ru
20100221 22:00:36-!- rolando [~rolando@3.38.103.87.rev.vodafone.pt] has quit [Ping timeout: 276 seconds]
20100221 22:00:54< Chusslove> stikonas: That would be ok. (I only intend to check it against raw Unicode order.)
20100221 22:02:13< stikonas> Chusslove: http://stikonas.homelinux.org/files/help.png
20100221 22:02:15-!- rolando [~rolando@3.38.103.87.rev.vodafone.pt] has joined #wesnoth-dev
20100221 22:03:08< stikonas> the order is somewhat random
20100221 22:03:22< Chusslove> Hm, right...
20100221 22:03:45< stikonas> I have something similar in lt, but not to that extent
20100221 22:04:04< stikonas> since Lithuanian language only has a few non-ASCII letters
20100221 22:04:50< stikonas> Chusslove: I think I see why it is ordered that way
20100221 22:05:01< stikonas> it completely ignores the first lette
20100221 22:05:17< stikonas> ant sorts using the second letter
20100221 22:05:26< Chusslove> Damn, that's exactly what it looks like!
20100221 22:05:34< stikonas> this is a bug...
20100221 22:05:51< Chusslove> I.e. it seems it ignores the capital letter, and sr is then fine because unit names are lower case.
20100221 22:06:22< stikonas> I'll submit a bug report
20100221 22:13:18< stikonas> wesbot: topic
20100221 22:13:20-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 74 bugs, 249 feature requests, 8 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100221 22:16:06-!- Appleman1234 [~Appleman1@131.181.102.222] has joined #wesnoth-dev
20100221 22:20:59< silene> Crab_: i guess that a userdata should be used, due to the two heavy fields; don't store unit_map iterators in the userdata though; replace them by something else, e.g. underlying ids
20100221 22:21:16< Crab_> ok
20100221 22:21:26-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20100221 22:21:58-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100221 22:22:58-!- fendrin [~fabi@wesnoth/developer/fendrin] has quit [Remote host closed the connection]
20100221 22:23:30< Crab_> silene: regarding: "you are not allowed to call functions that can raise an error (e.g. getfield, luaL_check, and so on) when C++ objects are in scope" - does this extend to c++ primitive types ? e.g. in your code I see things like "int x = luaL_checkint(L, 1); int y = luaL_checkint(L, 2);" - will we leak if the second luaL_checkint jumps out ?
20100221 22:24:05< silene> no, "int" is not a C++ class
20100221 22:24:46< silene> you can only use this function if the code could be compiled by a C compiler
20100221 22:24:57< Crab_> ok, thanks
20100221 22:25:40< silene> Crab_: search for "if (false)" in the code
20100221 22:26:03-!- Zarel [~Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20100221 22:26:45< Crab_> silene: yes, I suppose that you're using such code snippets to 'jump out' to them and force destruction of c++ objects already allocated - is this correct ?
20100221 22:27:01< silene> yes
20100221 22:30:04-!- Zarel [~Zarel@warzone2100/developer/Zarel] has quit [Client Quit]
20100221 22:30:13< freim> I've recently done the move subversion->git at work, there's several options for the migration that's quite straight-forward
20100221 22:30:27< Crab_> silene: and, the last question for today (thanks for all those answers!):  if luaW_pcall is the last statement in the function and I don't care about the return value, should I still check it and do something lua-specific ? ( see the end of  lua_ai_action_handler::handle, lua_action_handler::handle )
20100221 22:31:18< Crab_>  ( I don't care about the return value because success of ai actions is easier to check indirectly through the 'has gamestate changed?' question )
20100221 22:31:43< freim> I recommend svn2git as git-svn needs some manual fiddling to keep branches and stuff
20100221 22:32:03< silene> Crab_: no, the fact that it is the last call of the function is not relevant; the point is, lua_action_handler::handle doesn't expect any value from the user code, so there is nothing to check
20100221 22:32:59< silene> more precisely, what the return value of luaw_pcall says is whether there are elements on the stack or not
20100221 22:34:25-!- fendrin [~fabi@88-134-102-127-dynip.superkabel.de] has joined #wesnoth-dev
20100221 22:34:25-!- fendrin [~fabi@88-134-102-127-dynip.superkabel.de] has quit [Changing host]
20100221 22:34:25-!- fendrin [~fabi@wesnoth/developer/fendrin] has joined #wesnoth-dev
20100221 22:34:43< Crab_> silene: ok, understood. btw, if you'll need to disable the code for the release, the easiest way is to just disable the lua engine in src/ai/registry.cpp , lines 60-61
20100221 22:34:55< stikonas> freim: wasn't svn2git designed for one time conversion only? git-svn works in both directions
20100221 22:35:08< stikonas> certainly svn2git is better for final migration
20100221 22:36:02< freim> yes, I was thinking about final migration
20100221 22:36:21< stikonas> but until 1.8 is out it probably isn't an acceptable solution
20100221 22:36:53-!- EdB [~EdB@tss37-1-89-84-18-220.dsl.club-internet.fr] has quit [Remote host closed the connection]
20100221 22:36:56< stikonas> both KDE and Gnome used svn2git, so it should be quite mature
20100221 22:36:57< freim> one of our devs where using git-svn for quite a while also, I can ask him about it
20100221 22:37:03< freim> should work finer
20100221 22:37:06< freim> fine*
20100221 22:37:31< Ivanovic> freim: mordante is using git-svn and IIRC silene and Soliton are doing so, too
20100221 22:37:38< Ivanovic> so it does work as a tool
20100221 22:37:42< freim> yeah
20100221 22:42:33-!- wesbot changed the topic of #wesnoth-dev to: string/feature freeze active! | 75 bugs, 249 feature requests, 8 patches | logs: http://irclogs.wesnoth.org/ | Don't paste on IRC! Use a pastebin: http://wesnoth.pastebin.com | http://imagebin.org
20100221 22:43:56< silene> yes, i'm using git whenever possible (that is, for all the vcs except cvs)
20100221 22:44:45-!- Zarel [~Zarel@warzone2100/developer/Zarel] has joined #wesnoth-dev
20100221 22:51:15-!- silene [~plouf@wesnoth/developer/silene] has quit [Quit: Leaving.]
20100221 22:59:56-!- Espreon [~espreon@wesnoth/developer/espreon] has joined #wesnoth-dev
20100221 23:12:55< esr> wesbot: seen mordante
20100221 23:12:55< wesbot> esr: The person with the nick mordante last spoke 1h 35m ago.  1h 35m ago was here and on the channel #wesnoth-de with the message: Quit: Leaving
20100221 23:13:49< esr> Ivanovic: I think git-svn is a gpood transtion aid but not a long-term solution
20100221 23:14:09< boucman> esr: no worries, I think we all agree on that
20100221 23:14:27< Ivanovic> esr: at least it is a tool for the intermedeate problems we are facing with new features that can't go into trunk directly
20100221 23:14:40< esr> Ivanovic: And, do you have mordante's email?  I want to send him some private mail.
20100221 23:15:12< Ivanovic> if it was not for the current problems that delay 1.8 *extremely* by now there would not really be a need for "better branching support" at all
20100221 23:15:24< Ivanovic> esr: you have it, too
20100221 23:15:33< Ivanovic> just copy it from his last mails to the dev ml
20100221 23:15:53< esr> I'll look.
20100221 23:15:57< Crab_> esr: koraq@xs4all.nl
20100221 23:16:13< Ivanovic> Crab_: ehm, plain text email addys in a logged chan is not nice
20100221 23:16:14< boucman> Crab_: beware of spambots
20100221 23:16:25< Chusslove> stikonas: I've just rebuilt, and I don't see the sorting problem (e.g. for ru).
20100221 23:16:38< Chusslove> Don't know if some fixed it in the meantime :)
20100221 23:16:46< Crab_> Ivanovic, boucman: I checked google before placing it there, it's already public
20100221 23:16:56< boucman> k
20100221 23:18:20< Crab_> for example, there's nice list there http://packages.debian.org/changelogs/pool/main/w/wesnoth/wesnoth_1.6.5-1/wesnoth-nr.copyright :)
20100221 23:21:32< stikonas> anyway, email obfuscation if not a difficult problem for AI to solve it, much easier than captcha's
20100221 23:21:40< stikonas> s/if/is/
20100221 23:22:37< stikonas> Chusslove: strange, I still see it
20100221 23:23:12< stikonas> ok, I'll rebuild my locales, will see if it helps
20100221 23:24:59< stikonas> loonycyborg: can you check if the sorting of units in your Russian version of Wesnoth if correct, or it looks like this: https://gna.org/file/help.png?file_id=8210
20100221 23:26:14-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20100221 23:28:32< loonycyborg> stikonas: It seems to be sorted alphabetically for me.
20100221 23:29:16< stikonas> so this is probably mine problem
20100221 23:29:33< loonycyborg> http://imagebin.org/85928
20100221 23:30:39< stikonas> and I have no idea how to fix it
20100221 23:32:08< Chusslove> stikonas: For sake of completeness, dumb question: your LANG or LC_ALL is set to an existing locale (one reported by locale -a)?
20100221 23:32:20< Crab_> stikonas: works correctly for me, too
20100221 23:32:48< stikonas> they are all set to lt_LT.UTF-8
20100221 23:32:58< stikonas> yeah, this may be the problem
20100221 23:34:39< Ivanovic> sorting looks rather correct to me in russian, no idea though since i don't know the lang
20100221 23:35:32< loonycyborg> You can compare to screenshot I posted :P
20100221 23:35:44< stikonas> so it is not reproducible...
20100221 23:35:45< Ivanovic> http://imagebin.org/85929
20100221 23:35:54< Ivanovic> loonycyborg: or you can just tell me if this is correct or not...
20100221 23:36:02< stikonas> it is correct
20100221 23:36:05< Ivanovic> and no, i doN't think that i got a russian locale installed
20100221 23:36:30< Ivanovic> since i get those lovely "20100221 23:32:40 warning general: setlocale() failed for 'ru_RU'." messages
20100221 23:36:44< loonycyborg> Maybe that must be unicode magic..
20100221 23:37:08< Chusslove> Then it should use raw Unicode sorting, which I think yields same result as Russian collation.
20100221 23:37:16 * loonycyborg sucks at using modal verbs :P
20100221 23:37:18< Ivanovic> probably
20100221 23:37:43-!- boucman [~rosen@wesnoth/developer/boucman] has joined #wesnoth-dev
20100221 23:38:23-!- zookeeper [~l@wesnoth/developer/zookeeper] has quit []
20100221 23:38:35< Chusslove> With stikonas' screenshot it's downright weird, as if it's ignoring the (first) capital letter.
20100221 23:39:32< Chusslove> As if lower-casing (used to ignore case on sorting) is not working.
20100221 23:40:37< stikonas> Chusslove: I have deleted my locales, and now it sorts correctly (presumably using unicode collation)
20100221 23:43:57-!- boucman [~rosen@wesnoth/developer/boucman] has quit [Quit: Leaving.]
20100221 23:44:08-!- Appleman1234 [~Appleman1@131.181.102.222] has quit [Ping timeout: 268 seconds]
20100221 23:44:47< stikonas> so it seems that non-unicode collation is broken
20100221 23:45:26-!- Appleman1234 [~Appleman1@131.181.102.222] has joined #wesnoth-dev
20100221 23:45:36< Chusslove> If you reinstall locales, and then set another locale instead of lt_LT?
20100221 23:46:45-!- Appleman1234 [~Appleman1@131.181.102.222] has quit [Excess Flood]
20100221 23:47:12-!- Appleman1234 [~Appleman1@131.181.102.222] has joined #wesnoth-dev
20100221 23:49:04< stikonas> Chusslove: I've just regenerated my locales, ant sorting still doesn't work with LC_ALL=C and LANG=C
20100221 23:49:46< Chusslove> C is a bit so-so (it should tell "ignore locales"), so use a normal locale.
20100221 23:50:00< Chusslove> e.g. en_US.UTF-8
20100221 23:51:56< stikonas> neither en_US.UTF-8, nor de_DE.UTF-8 work
20100221 23:57:15< Ivanovic> stikonas: the "problem" is that the game will switch to your systems locale when you select that one ingame
20100221 23:57:27< Ivanovic> unless you don't have the locale, then just the messages or something like this are switched
20100221 23:57:49< Ivanovic> so your startparam does *not* make a real difference once you have switched away from "use system language" in the lang selection
20100221 23:58:22< stikonas> so probably none of you have generated ru locale
20100221 23:58:28< stikonas> so Wesnoth uses unicode collation
20100221 23:59:13< Ivanovic> might be that loonycyborg has the ru locale, no idea
20100221 23:59:39< Chusslove> I have ru locale too (and Wesnoth is not reporting it missing in the shell output).
--- Log closed Mon Feb 22 00:00:20 2010