1.9 Cup system

[MarkC]

If you define a cup with a round robin stage, but fail to include the <new_teams> tag, the program gets the week numbers wrong, because it relies on <new_teams> to tell it how many teams are taking part. (Function cup_round_get_number_of_teams.)

Easy fix: Change the HOWTO to state that <new_teams> is required in round robins as well as rounds with "generated" teams.

Hard fix: I don't know but this cup_round_get_number_of_teams function looks to be broken because it relies on new_teams being set correctly in every round, whether knockout or round robin. I think it's only used for round robins at the moment though.

[gyboth]

If you define a cup with a round robin stage, but fail to include the <new_teams> tag, the program gets the week numbers wrong, because it relies on <new_teams> to tell it how many teams are taking part.

was this the first round or a later one? could you maybe post your definition files so that i can test my fixes?

Easy fix: Change the HOWTO to state that <new_teams> is required in round robins as well as rounds with "generated" teams.

i don't think i like this way of fixing things the xml definition files should be as simple and clear as possible, and the code should be as general and flexible as possible.

Hard fix: I don't know but this cup_round_get_number_of_teams function looks to be broken because it relies on new_teams being set correctly in every round, whether knockout or round robin. I think it's only used for round robins at the moment though.

yes, after taking a look at it i also think it's broken. it doesn't work well for knockout rounds either because it doesn't take into consideration the teams that got a bye (not to mention that round robin stages can have byes, too).

i'm going to try to fix it tonight. thanks for reporting.

gyözö

[gyboth]

the corresponding code is a bit uglier now but the problem should be fixed (i hope). please try it out with the definition that caused the problem initially.

gyözö

[MarkC]

i don't think i like this way of fixing things

Good, I don't either. In fact, I don't think "fix" is the correct word

the corresponding code is a bit uglier now but the problem should be fixed (i hope). please try it out with the definition that caused the problem initially.

OK, thanks. The new CVS code isn't available yet so I'll test it when it appears.

Yes, I can imagine the code is uglier now. I think there might be a better way of handling cups, but it would be a major change. If I get chance to play around with this and find anything worth suggesting, I'll let you know.

Mark

[gyboth]

OK, thanks. The new CVS code isn't available yet so I'll test it when it appears.

one more reason to make an sf.net account for devs the cvs is instantly available (i don't have a clue why).

Yes, I can imagine the code is uglier now. I think there might be a better way of handling cups, but it would be a major change.

a better way? impossible seriously, what do you have in mind?

gyözö

[MarkC]

one more reason to make an sf.net account for devs the cvs is instantly available (i don't have a clue why).[.quote]

I know, I know, I'm getting there!

a better way? impossible seriously, what do you have in mind?

I haven't thought this through very well yet, but...

I was thinking of creating a whole cup "framework" as soon as the cup begins, instead of generating one round at a time. Similar to drawing out the cup tree on paper, then copying the winners across as the rounds are completed. I really don't want to type too much until I've thought about it a bit more

I think this might allow a bit more flexibility in cup definitions, but my main reason is that I think it would make the code simpler and easier to follow. All the hard work of calculating week numbers, deciding byes and generating choose_teams (for all the rounds) could be done at once when the cup starts. Then there could be very simple functions to return things like team lists and week numbers for rounds. I suppose I'm taking a sort of "object-orientated" approach but keeping my thoughts tied to C.

Really this is just a passing thought. The advantages might not be as great as I'm imagining.

Mark

[gyboth]

I know, I know, I'm getting there!

hehe, he's getting there

I was thinking of creating a whole cup "framework" as soon as the cup begins, instead of generating one round at a time. Similar to drawing out the cup tree on paper, then copying the winners across as the rounds are completed. I really don't want to type too much until I've thought about it a bit more

would the framework be specified in the definition files? if yes, i'm against it, i think. only freaks like you and me would create definitions if the syntax gets that complicated. it's alreay complicated enough right now, i'd say.
if no, you'd have to generate the framework from a simple-syntax def file, which would lead to code similar to the current one.

I think this might allow a bit more flexibility in cup definitions, but my main reason is that I think it would make the code simpler and easier to follow. All the hard work of calculating week numbers, deciding byes and generating choose_teams (for all the rounds) could be done at once when the cup starts.

i don't think so. obviously you can't know which teams take part in later rounds (except for teams that come into the cup only then), so you don't know who's getting byes either (if you want the high-league teams to get automatic byes). of course one could avoid this bye-problem by creating the definition file carefully, but as i said, i'm hoping for definition files from users, not programmers (since there are a lot more users than programmers).

Then there could be very simple functions to return things like team lists and week numbers for rounds. I suppose I'm taking a sort of "object-orientated" approach but keeping my thoughts tied to C.

Really this is just a passing thought. The advantages might not be as great as I'm imagining.

i don't know. i fully agree that a lot of functions in cup.c don't look very 'justified', they're called only by one other function and do a very specific job. but this is also the reason the definition files can be as (relatively) simple as they are, giving just two week values, and the fixtures and week numbers etc. are calculated automatically.

i also think the choose_team system and the corresponding functions, and the fixture generation is ok. the fixture generation and choose_team generation is done in 3-5 functions each, that's not too many.

anyway, think about your ideas a bit longer and maybe we can have a great solution using the best parts of each approach (thus rendering the code completely unreadable and cryptic ).

gyözö

[MarkC]

OK, I really don't want to dwell on this too much

would the framework be specified in the definition files? if yes, i'm against it...

Oh, no! I meant the code would generate it from the existing XML format. I totally agree that the definitions have to be kept as simple as possible.

if no, you'd have to generate the framework from a simple-syntax def file, which would lead to code similar to the current one.

Yes, the code would be similar, but I imagined it being a bit more organised. I thought of the program creating a cup tree with empty "slots" in all the rounds, loading all the choose_teams into the correct rounds at the start, then moving winners down the tree as each round is completed. It just feels like there is more of a plan.

so you don't know who's getting byes either

Sorry, I wasn't clear. I just meant that the program would work out how many byes would be needed in each round, and therefore could check in advance to make sure that the cup was well-defined, with the correct number of rounds and so on, instead of just suddenly "noticing" in week 40 that the cup doesn't quite work out.

OK, I've realised that the only big advantage to the framework is that it makes it easier to check for an invalid definition. Once you know a cup is well-defined, I don't think the framework idea actually helps much. It would just involve a different style of coding.

So let me make a simpler suggestion. What about including code to check definitions before the game starts? I think it'd be a good idea, after loading a country, to check that all the cups and leagues have a valid structure. For example, valid choose_teams, correct number of rounds, correctly balanced promotion/relegation between leagues. If it finds a problem, it can exit cleanly and give a proper error message. It's possible that I could be persuaded to work on this if you like the idea but don't fancy coding it

Advantages:
Bad definitions would no longer cause segfaults. This is a major issue IMO. A program should never segfault just because it receives bad data.
Errors would be caught straight away, instead of only being reported when they actually cause a problem. It'd be a lot easier to create correct definitions.

Disadvantage:
The checking code would have to be kept up to date with changes to the definition file formats (extra tags, etc.)

Anyway, I've said a lot more than I meant to, and we're going way off topic Let's drop this thread. This belongs in feature suggestions, if anywhere.

[gyboth]

Yes, the code would be similar, but I imagined it being a bit more organised. I thought of the program creating a cup tree with empty "slots" in all the rounds, loading all the choose_teams into the correct rounds at the start, then moving winners down the tree as each round is completed. It just feels like there is more of a plan.

so the only difference to the current way would be the tree, right? one thing i don't get is, what do you mean by 'moving teams'? would the levels (rows?) of the tree contain team pointer arrays? and, thinking a bit more: what would be the leafs of the tree? teams?

So let me make a simpler suggestion. What about including code to check definitions before the game starts? I think it'd be a good idea, after loading a country, to check that all the cups and leagues have a valid structure. For example, valid choose_teams, correct number of rounds, correctly balanced promotion/relegation between leagues. If it finds a problem, it can exit cleanly and give a proper error message. It's possible that I could be persuaded to work on this if you like the idea but don't fancy coding it

i also think this would be a good idea. it would make creating def files a lot easier, especially for beginners. so, i like the idea; and i don't fancy coding it, either i'd be grateful if you'd do it if you find the time (of course i'd accept a 'no, thanks, not the type of coding i enjoy doing in my free time' as well )

Bad definitions would no longer cause segfaults. This is a major issue IMO. A program should never segfault just because it receives bad data.

maybe... i'm not a programmer, you know. i know next to nothing about programming conventions. i think, it's ok if the program segfaults if there's a warning/error message before the segfault giving a hint on why it happens.

Errors would be caught straight away, instead of only being reported when they actually cause a problem. It'd be a lot easier to create correct definitions.

yes. this is absolutely true.

Anyway, I've said a lot more than I meant to, and we're going way off topic Let's drop this thread. This belongs in feature suggestions, if anywhere.

we can't drop a thread without tying up the loose ends, can we

gyözö

[MarkC]

so the only difference to the current way would be the tree, right? one thing i don't get is, what do you mean by 'moving teams'? would the levels (rows?) of the tree contain team pointer arrays? and, thinking a bit more: what would be the leafs of the tree? teams?

Remember that I hadn't really thought about it much when we started this thread
Originally, I was imagining the kind of tree you'd draw out on paper if you wanted to plan a tournament draw. You know the kind of thing I mean - pairs of boxes (or groups for a RR stage) with lines linking them to the next round to show winners advancing, and so on. The point is that there would be a plan showing clearly at which round each team comes in, and if and how many byes are needed per round. Taking the FA Cup as defined in bygfoot, we'd see 70 teams entering in round 1 with 10 byes, and 44 teams entering in round 3. The names of all 114 teams can written in the correct place in the tree before the tournament even starts.

I've since realised that creating an entire, detailed tree with pairs of slots isn't necessary or useful, since we can just pair the teams when the round starts like we do now. So that just leaves lists of teams in each round, which is basically what we have already. The only real difference, apart from being able to check that the definition works, is that I imagined loading all the choose_teams for every round as soon as the cup starts, instead of loading them in the week they start playing. This does actually allow for more flexible defs. A silly little example:

Round 1: choose teams 3-6 from league 1
Round 2: choose teams 1-2 from league 1
Final.

This isn't possible at the moment, because by the time round 2 starts, all the teams' positions have changed! The only option is to use random byes.

In short, I don't think that the actual framework/tree/plan whatever is worth thinking about any more, but bits of the idea might be worth looking at. The main reason for the idea was that it would allow a check to be done on the cup definition. Speaking of which:

i also think t his would be a good idea. it would make creating
def files a lot easier, especially for beginners. so, i like the idea;
and i don't fancy coding it, either i'd be grateful if you'd do it
if you find the time (of course i'd accept a 'no, thanks, not the
type of coding i enjoy doing in my free time' as well )

I'll see what I can do The only other way I can think of to stop the segfaults is to do proper error checking at the points where crashes actually occur. This would make the code very ugly. By checking at the start of the game, you can allow the rest of the code to assume the defs are correct, which keeps it simple and easier to read and maintain.

Bad definitions would no longer cause segfaults. This is a major issue IMO. A program should never segfault just because it receives bad data.

maybe... i'm not a programmer, you know. i know next to nothing about programming conventions. i think, it's ok if the program segfaults if there's a warning/error message before the segfault giving a hint on why it happens.

Not a programmer? You've done a pretty good job!

Apart from not catching segfaults, of course
Perhaps "major issue" was a bit too strong. It's just a lot cleaner to catch bad data, give a nice message, free your dynamic memory, close your files and exit properly, rather than just crash and leave the operating system to clean up. Don't forget that a process can leave a core dump file behind when it crashes, although most Linux distributions have them switched off by default for ordinary users. It's never nice to have these lying around.

Segfaults can also be potential security holes. In the case of bygfoot this isn't really an issue as it should never be running with any special privileges, but it's still best to try and avoid crashes just to remove any doubt! If you intend to release 1.9 into Debian then I'm pretty sure you'll get people reporting segfaults as bugs.

we can't drop a thread without tying up the loose ends, can we

No, I suppose not I just didn't want to keep going on too much about that cup idea without thinking it through first.

[gyboth]

I've since realised that creating an entire, detailed tree with pairs of slots isn't necessary or useful, since we can just pair the teams when the round starts like we do now. So that just leaves lists of teams in each round, which is basically what we have already.

exactly

The only real difference, apart from being able to check that the definition works, is that I imagined loading all the choose_teams for every round as soon as the cup starts, instead of loading them in the week they start playing. This does actually allow for more flexible defs.

true. this would be a bigger change, though, because the current cup and cup round structures don't support storing team pointers (except for the pointers to all generated teams).

Not a programmer? You've done a pretty good job!

thanks i've never taken courses or written anything else apart from Bygfoot (and, for a few weeks, Greyhounds which was my first experience with GTK).

Apart from not catching segfaults, of course

Perhaps "major issue" was a bit too strong. It's just a lot cleaner to catch bad data, give a nice message, free your dynamic memory, close your files and exit properly, rather than just crash and leave the operating system to clean up. Don't forget that a process can leave a core dump file behind when it crashes, although most Linux distributions have them switched off by default for ordinary users. It's never nice to have these lying around.

i've taken a look at the source code (cup.c). it seems that choose team load errors lead to freeing the memory and exiting cleanly. i'm not sure where the other crashes occur.

If you intend to release 1.9 into Debian then I'm pretty sure you'll get people reporting segfaults as bugs.

no, i think only 2.0 will come into debian. i never had development releases in debian.

i'm moving the topic to 'code discussions' and change the title to something more appropriate .

gyözö