Nils Kneuper | 2 Feb 11:31 2012
Picon
Picon

Re: FOSDEM 2012: preparations, packlist, ...


Hi everybody!
Just to once more make everyone aware of FOSDEM starting on Saturdays. Us
Wesnoth folks will meet on Friday evening already and probably have some
dinner at the Greek restaurant called "Santorini". So if we missed each other
before, just head over there and some of us Wesnoth people might eventually
join in...

By now there are even weather forecasts available and it seems to be getting
cold and there is a chance that we might even get some snow. So don't forget
to bring clothes fitting for this situation, just a t-shirt might not be
enough. ;)

And for those who missed the mail before (or are too lazy to search for it):
You can find the original mail with the packlist at the end of this mail.

Cheers,
Nils Kneuper aka Ivanovic

Am 24.01.2012 10:54, schrieb Nils Kneuper:
> Hi everybody! Just a little more than one week left till FOSDEM 2012
> starts. Because of this a short reminder regarding stuff you should make
> sure to bring if you want to join:
> 
> 1) Stuff you should not forget to package: - Bring Euro coins (2, 1, .5, .2
> and .1)! The reason is simple: Close to the hacking room is a vending
> machine that is a little cheaper than the official sale of drinks at FOSDEM
> and the drinks are cooled. The problem: you need coins to feed it! Beside
> this buying tickets is cheaper when getting them from the machines
> available at basically every station. When buying from the driver you pay a
(Continue reading)

Nils Kneuper | 2 Feb 12:10 2012
Picon
Picon

Re: FOSDEM 2012: preparations, packlist, ...


> Am 24.01.2012 10:54, schrieb Nils Kneuper:
>> 3) As the last years we will most likely conquer the first row of the 
>> hacking room AW1.115. So if we don't meet before, you should be able to 
>> find some Wesnoth people there (on Saturday). On Sunday it is likely
>> that some (or even most?) Wesnoth devs will be in AW1.120, the devroom
>> centered on open source game development.

Wow, looks like there was a change here. The hacking room in the AW building
seems to now be AW1.117. The room right next door from 115.
Cheers,
Nils Kneuper aka Ivanovic
Oleg Tsarev | 4 Feb 17:07 2012
Picon

save_index file - purposes and current state

Hello guys,

I investigated "save_index" and confused by several things. General questions:

1) Which the reason create save_index file?
If I right understood, only two purposes:
 a) decrease time of open "Load" dialog
 b) decrease time of render clicked save - show preview, game
description, company name, etc.

Perfomance reason, other words. Please approve/disapprove my understanding.

2) Unfortunatelly, right now "save_index" does not used by anywhere in game.

I see just single call of save_index: write_save_index() (I skipped
definition of class and definition of methods):

src/savegame.hpp:	/** Update the save_index */
src/dialogs.cpp:		config& cfg = savegame::save_index::save_summary(i->name);
src/dialogs.cpp:	savegame::save_index::write_save_index();

You can check this by "find ./src -exec grep save_index". From this
point of view, right now save_index nobody used.
I also checked it by stacktraces *(see end of letter)

In typical game usage nowhere is used :(

3) I supposed - save_index used before, but right now code with usage
removed. I investigated revision history by git bisect and can't
confirm this -
(Continue reading)

Jörg Hinrichs | 6 Feb 08:41 2012
Picon

Re: save_index file - purposes and current state

Hi Oleg,

I will try and answer your questions. Please bear in mind, though, that my
knowledge is from BfW 1.8. If things have changed since then, I might be
wrong on something I tell here.

1)
Yes, save_index was created due to performance reasons. The main difficulty
is presenting the load_game dialog. 

For that, you don't only have to know all the filenames: You also need to
investigate about all the things that are presented when a game is selected
in the list, namely map, turns, hero-icon etc.

To get those, you would have to (fully) parse every savefile which would
take very long.

The save_index stores all that information for every save. It's actually not
that much WML, but as said before, it is tedious to evaluate otherwise.

2)
Save_index is controlled by a class with the same name, that consists only
of static members. It is meant to represent globally available functionality
and you are not supposed to create instances of this class.

This class has a static member save_index_cfg, which gets filled by calling
save_index::load(), which in turn is done in save_index::save_summary as
well as save_index::write_save_index.
This config is meant to hold all the game information that needs to be
presented in the load_game dialog.
(Continue reading)

Evgeniy Stepanov | 6 Feb 09:57 2012
Picon

Re: save_index file - purposes and current state

Hi,

On Mon, Feb 6, 2012 at 11:41 AM, Jörg Hinrichs
<joerg.hinrichs <at> alice-dsl.de> wrote:
> Hi Oleg,
>
> I will try and answer your questions. Please bear in mind, though, that my
> knowledge is from BfW 1.8. If things have changed since then, I might be
> wrong on something I tell here.
>
> 1)
> Yes, save_index was created due to performance reasons. The main difficulty
> is presenting the load_game dialog.
>
> For that, you don't only have to know all the filenames: You also need to
> investigate about all the things that are presented when a game is selected
> in the list, namely map, turns, hero-icon etc.
>
> To get those, you would have to (fully) parse every savefile which would
> take very long.
>
> The save_index stores all that information for every save. It's actually not
> that much WML, but as said before, it is tedious to evaluate otherwise.
>
>
> 2)
> Save_index is controlled by a class with the same name, that consists only
> of static members. It is meant to represent globally available functionality
> and you are not supposed to create instances of this class.
>
(Continue reading)

Fabian Mueller | 15 Feb 00:41 2012
Picon
Picon

Re: save_index file - purposes and current state

On 02/06/2012 08:41 AM, Jörg Hinrichs wrote:
>
> You might also be right, that this information is not used anymore. When I
> refactored the savegame functionality together with euschn, I also created a
> new load_game dialog that uses the Gui2-framework of mordante. The new
> dialog was optional and back then could be used by starting Wesnoth with the
> command line parameter --new_widgets.
The situation hasn't changed since then.
Gui1 is the default and you get the gui2 load_game dialog with the 
--new_widgets parameter.
>
>
> The old dialog still relied on save_index, if I remember correctly.
My observations support that this is still the case as well.
Whenever the gui1 dialog is used to load a game in a different difficult 
level, the difficult level the savegame
is from seems to have changed.
This is not the case, so the loading of the savegame must have triggered 
an update to the save_index without
any write access to the file happened.

It would be nice to get rid of both, the gui1 dialog and the save_index.
Gui2 does not support the filtering and sorting of lists, so this is 
still blocked for some time.

I will see what happens to the save_index and fix the bug related to the 
load game with difficulty depending on the outcome.

Fabian
(Continue reading)

Oleg Tsarev | 15 Feb 03:20 2012
Picon

Re: save_index file - purposes and current state

I found: save_index used.
I reafactored it little.

2012/2/15 Fabian Mueller <fabianmueller5 <at> gmx.de>:
> On 02/06/2012 08:41 AM, Jörg Hinrichs wrote:
>>
>>
>> You might also be right, that this information is not used anymore. When I
>> refactored the savegame functionality together with euschn, I also created
>> a
>> new load_game dialog that uses the Gui2-framework of mordante. The new
>> dialog was optional and back then could be used by starting Wesnoth with
>> the
>> command line parameter --new_widgets.
>
> The situation hasn't changed since then.
> Gui1 is the default and you get the gui2 load_game dialog with the
> --new_widgets parameter.
>
>>
>>
>> The old dialog still relied on save_index, if I remember correctly.
>
> My observations support that this is still the case as well.
> Whenever the gui1 dialog is used to load a game in a different difficult
> level, the difficult level the savegame
> is from seems to have changed.
> This is not the case, so the loading of the savegame must have triggered an
> update to the save_index without
> any write access to the file happened.
(Continue reading)

Mark de Wever | 15 Feb 20:36 2012
Picon
Picon

GSoC 2012

Hi,

At the FOSDEM Google announced that there will be a GSoC [1] again. We
also discussed whether or not to join, but decided it would be better to
discuss on this mailing list.

Some points we discussed at the FOSDEM were:
* GSoC mentoring and preparation cost a lot of time and that time
  especially mentoring is done by core developers, who can not use that
  time to hack on Wesnoth.
* The amount of students that stay is rather low. The whole idea of GSoC
  is to gain new students and keep them. The disadvantages are:
  * The project is abandoned after the summer.
  * The mentor suddenly has an extra feature to maintain.
  * Getting a new student up to speed takes quite some effort, so it
    would have been faster if the mentor did the work him/herself. This
    should pay itself back by gaining a new developer. The first
    happens, the second too little. (That it takes time and is faster to
    do it oneself is expected, just like training a new colleague.) 

So the question is do we want to join?
Who will be available as mentor?
Who will be available as project administrator?

[1] http://code.google.com/soc/
--

-- 
Regards,
Mark de Wever aka Mordante/SkeletonCrew
Iurii Chernyi | 15 Feb 20:48 2012
Picon

Re: GSoC 2012

I would like to mentor.

Also, I think that even if a student doesn't stay, there are ample
benefits in GSOC:
 - we think more about areas which need improvement.
 - together with students, we explore various ways of approaching the
problems we face.
 - we gain more visibility for other, potential developers (even outside GSoC).
 - it's fun.

On Wed, Feb 15, 2012 at 8:36 PM, Mark de Wever <koraq <at> xs4all.nl> wrote:
> Hi,
>
> At the FOSDEM Google announced that there will be a GSoC [1] again. We
> also discussed whether or not to join, but decided it would be better to
> discuss on this mailing list.
>
> Some points we discussed at the FOSDEM were:
> * GSoC mentoring and preparation cost a lot of time and that time
>  especially mentoring is done by core developers, who can not use that
>  time to hack on Wesnoth.
> * The amount of students that stay is rather low. The whole idea of GSoC
>  is to gain new students and keep them. The disadvantages are:
>  * The project is abandoned after the summer.
>  * The mentor suddenly has an extra feature to maintain.
>  * Getting a new student up to speed takes quite some effort, so it
>    would have been faster if the mentor did the work him/herself. This
>    should pay itself back by gaining a new developer. The first
>    happens, the second too little. (That it takes time and is faster to
>    do it oneself is expected, just like training a new colleague.)
(Continue reading)

Mark de Wever | 15 Feb 20:56 2012
Picon
Picon

Wesnoth project hosting

Hi,

At the FOSDEM we discussed again about whether or not moving to git and
thus from the location our source repository is hosted. The discussion
is listed [1] under Git.

Personally I see not too much advantage by Git, git-svn works good
enough for me. However IMO the uptime of GNA is getting lower over the
years (it might be selective memory as well). So moving to another
place to host our source repository might be a good idea. Am I the only
one who thinks it would be a good idea to try to find a more reliable
hosting party? Note moving to another hosting party does not mean
switching to Git per se.

How do we feel about moving to Git? As said I see not too much advantage
by Git, but I'm not opposed to move. If so are there preferences over
the hosting party? Rhonda also said she can probably host Git for us.

If we decide to move, do we only want to move the source repository or
also the bug-tracker and mailing lists? I haven't investigated whether
or not it's possible to export our bug-tracker's contents.

[1] http://wiki.wesnoth.org/FOSDEM2012#Mordante.27s_.60email.27
--

-- 
Regards,
Mark de Wever aka Mordante/SkeletonCrew

Gmane