tuxmath-devel

[Tuxmath-devel] Patches & plans for tuxmath

[Tim H. <ho...@wu...>]

Hi,

First and foremost, thanks to all the people who have contributed to tuxmath, 
making it a great program that my family is benefitting from a lot.
Particular thanks Bill Kendrick for creating tuxmath and GPLing it, and to 
David Bruce for all the enhancements he's given it.

Because we're liking it so much, I thought I'd try to contribute a bit to the 
project. I'm new to contributing back to open source, so I'm probably not 
very sophisticated in my use of the tools.

Attached are two tiny enhancements:
1. (trivial) Provide a bit more description of what the play_through_list mode 
does---I kept trying to supply a text file for the problem list until I looked 
at the source code. The relevant patch file is mathcards.diff. This patch 
also adds a comment on a point that I initially found confusing.
2. On some systems (e.g., older, or perhaps even current, KDE systems using 
aRTs), sound hardware can be temporarily unavailable, because aRTs 
didn't/doesn't share the sound resources nicely. In that case, sound gets 
turned off. The problem is that this then gets saved as the user's preference 
for the next session. This is fixed in the other 3 patch files: config.diff, 
setup.diff, tuxmath.diff. (Presumably if I knew what I was doing I could have 
made this a single patch file?) Note my use of "verbose = 2" seems a bit 
cheesy, at least if you ever had anything else planned for gradations in 
verbosity---feel free to change this.

I'd also consider working on some more significant enhancements:
1. The options configuration screen doesn't reflect current reality all that 
well, especially with regards to the numerical ranges; my older daughter is 
working on her times table up to 10, and was briefly disconcerted to see "12" 
there even though I had manually edited the config file appropriately. The 
addition of the "speed" control is very nice; my daughters might also like to 
be able to control the game's acceleration (speedup_factor). So it might be 
nice to be able to give users more control over certain parameters.

Conversely, tuxmath is clearly to the point of being useful for classroom 
purposes---but there, a teacher might want to be able to prevent students 
from changing the assignments to "plus" when they're supposed to be working 
on "times." So, some method for allowing someone to set, say by a 
configuration file, which options should be "locked" (and not even show up on 
the options screen) could be a useful feature. (Of course there might be 
other ways of accomplishing the same thing, say, by watching the kids while 
they play!)

But if these thoughts make sense to others, it might be worth doing something 
of a general reworking of the options screen.

2. It strikes me that a good way to control the pace of the game might be 
through feedback. Many kids (in particular, mine) will probably have a 
comfort range: it's boring when it's too slow, and it's intimidating when 
it's too fast. Instead of controlling the speed directly, one might want to 
instead try to achieve a particular "adrenaline level." For example, one 
could specify in the configuration file that this kid loves the challenge 
when the problems frequently almost nuke the cities; another kid (using a 
different config file) might be more cautious and prefer it if the problems 
rarely get more than halfway down the screen. The game could adjust its speed 
to achieve, say, an average height at which the player zaps the problems. 
With braver players that level could be set lower (closer to smashing the 
cities), with more cautious players it could be set higher.

While this might work well for some players, an easily-foreseeable problem is 
that if kids discover the feedback, some of them might try to take advantage 
of it---or, if they decide for fun to "wait until the last minute" before 
zapping a problem, in order to try to build a sense of excitement, then the 
game will slow down rather than speeding up, perhaps contrary to what the kid 
himself/herself would actually prefer.

For that reason, one would of course want to be able to leave the current 
controls available, and have feedback only as an option. It might be 
especially good for the first-time user, to set the game to the appropriate 
level; one could choose to then fix the speed in the config file, for 
example.

However, giving the users direct control over speed & speedup might be just as 
good, or better, for achieving these aims---so it's not obvious that this 
would be a desirable feature. Discussion?



There are also a few other points I thought I should mention, but either I 
can't do anything about them or hesitate to do so without some input from 
those with more expertise:

1. Please, the tuxmath web page and the sourceforge page should both point to 
the current subversion tree. When I started hacking on it, I was going to use 
the CVS; but by chance I had first downloaded the sources from Debian 
unstable, and was surprised to see that these seemed newer and more 
featureful than the CVS. I then poked around and found the subversion tree, 
but it could have easily worked out differently, wasting a bunch of time.

2. Installing: the PREFIX=?? syntax doesn't work for me unless I take root 
privileges. It complains about the "chown" (here are the last 4 lines of 
output):

cp tuxmath /home/tim/src/tuxmath/build/bin
chown root:root /home/tim/src/tuxmath/build/bin/tuxmath
chown: changing ownership of `/home/tim/src/tuxmath/build/bin/tuxmath': 
Operation not permitted
make: *** [install] Error 1

I edited the Makefile to allow me to set OWNER, and that works the first time. 
However, when I modify & recompile, then I get a different problem: it turns 
out that the install script also copies all the .svn directories (presumably, 
this is not actually desirable?) and on these directories I get permission 
errors (because these files are locked for writing even by the owner).

Unfortunately, not being a C/C++ wiz I haven't had enough experience with 
Makefiles to solve this one easily myself. I tried putting in a
     cp $(find . | grep -v ".svn") $(DATA_PREFIX)
but I think make tries to interpret my shell command as a makefile variable. 
Anyone else know how to fix this? (Use rsync instead of cp? Or do some people 
not have that installed on their systems?)

3. In the configuration file, I've noticed that the ranges for subtraction are 
not specified as the complement of the addition problems---for that, one 
would specify "subtrahend" and "difference" rather than "minuend" 
and "subtrahend". This is in contrast with division, which is the complement 
of multiplication. One consequence is that kids get 121 addition problems if 
they go from 0 to 10, but many more subtraction problems that include 20-4=16 
etc. This is not a bug, and may not even be bad, but it's something I 
noticed. I can try to help change it if that's desirable.

Once again, thanks for a great program!
--Tim Holy

Re: [Tuxmath-devel] Patches & plans for tuxmath

[Tim H. <ho...@wu...>]

Hi again,

Oops, I guess I should have said:
mathcards.diff is to be applied to mathcards.c
tuxmath.diff applies to tuxmath.h
config.diff applies to config.c
setup.diff applies to setup.c

Surely there is a better way to do this, but I obviously haven't figured it 
out yet...sorry.

--Tim

On Monday 28 August 2006 10:23, Tim Holy wrote:
> Hi,
>
> First and foremost, thanks to all the people who have contributed to
> tuxmath, making it a great program that my family is benefitting from a
> lot. Particular thanks Bill Kendrick for creating tuxmath and GPLing it,
> and to David Bruce for all the enhancements he's given it.
>
> Because we're liking it so much, I thought I'd try to contribute a bit to
> the project. I'm new to contributing back to open source, so I'm probably
> not very sophisticated in my use of the tools.
>
> Attached are two tiny enhancements:
> 1. (trivial) Provide a bit more description of what the play_through_list
> mode does---I kept trying to supply a text file for the problem list until
> I looked at the source code. The relevant patch file is mathcards.diff.
> This patch also adds a comment on a point that I initially found confusing.
> 2. On some systems (e.g., older, or perhaps even current, KDE systems using
> aRTs), sound hardware can be temporarily unavailable, because aRTs
> didn't/doesn't share the sound resources nicely. In that case, sound gets
> turned off. The problem is that this then gets saved as the user's
> preference for the next session. This is fixed in the other 3 patch files:
> config.diff, setup.diff, tuxmath.diff. (Presumably if I knew what I was
> doing I could have made this a single patch file?) Note my use of "verbose
> = 2" seems a bit cheesy, at least if you ever had anything else planned for
> gradations in verbosity---feel free to change this.
>
> I'd also consider working on some more significant enhancements:
> 1. The options configuration screen doesn't reflect current reality all
> that well, especially with regards to the numerical ranges; my older
> daughter is working on her times table up to 10, and was briefly
> disconcerted to see "12" there even though I had manually edited the config
> file appropriately. The addition of the "speed" control is very nice; my
> daughters might also like to be able to control the game's acceleration
> (speedup_factor). So it might be nice to be able to give users more control
> over certain parameters.
>
> Conversely, tuxmath is clearly to the point of being useful for classroom
> purposes---but there, a teacher might want to be able to prevent students
> from changing the assignments to "plus" when they're supposed to be working
> on "times." So, some method for allowing someone to set, say by a
> configuration file, which options should be "locked" (and not even show up
> on the options screen) could be a useful feature. (Of course there might be
> other ways of accomplishing the same thing, say, by watching the kids while
> they play!)
>
> But if these thoughts make sense to others, it might be worth doing
> something of a general reworking of the options screen.
>
> 2. It strikes me that a good way to control the pace of the game might be
> through feedback. Many kids (in particular, mine) will probably have a
> comfort range: it's boring when it's too slow, and it's intimidating when
> it's too fast. Instead of controlling the speed directly, one might want to
> instead try to achieve a particular "adrenaline level." For example, one
> could specify in the configuration file that this kid loves the challenge
> when the problems frequently almost nuke the cities; another kid (using a
> different config file) might be more cautious and prefer it if the problems
> rarely get more than halfway down the screen. The game could adjust its
> speed to achieve, say, an average height at which the player zaps the
> problems. With braver players that level could be set lower (closer to
> smashing the cities), with more cautious players it could be set higher.
>
> While this might work well for some players, an easily-foreseeable problem
> is that if kids discover the feedback, some of them might try to take
> advantage of it---or, if they decide for fun to "wait until the last
> minute" before zapping a problem, in order to try to build a sense of
> excitement, then the game will slow down rather than speeding up, perhaps
> contrary to what the kid himself/herself would actually prefer.
>
> For that reason, one would of course want to be able to leave the current
> controls available, and have feedback only as an option. It might be
> especially good for the first-time user, to set the game to the appropriate
> level; one could choose to then fix the speed in the config file, for
> example.
>
> However, giving the users direct control over speed & speedup might be just
> as good, or better, for achieving these aims---so it's not obvious that
> this would be a desirable feature. Discussion?
>
>
>
> There are also a few other points I thought I should mention, but either I
> can't do anything about them or hesitate to do so without some input from
> those with more expertise:
>
> 1. Please, the tuxmath web page and the sourceforge page should both point
> to the current subversion tree. When I started hacking on it, I was going
> to use the CVS; but by chance I had first downloaded the sources from
> Debian unstable, and was surprised to see that these seemed newer and more
> featureful than the CVS. I then poked around and found the subversion tree,
> but it could have easily worked out differently, wasting a bunch of time.
>
> 2. Installing: the PREFIX=?? syntax doesn't work for me unless I take root
> privileges. It complains about the "chown" (here are the last 4 lines of
> output):
>
> cp tuxmath /home/tim/src/tuxmath/build/bin
> chown root:root /home/tim/src/tuxmath/build/bin/tuxmath
> chown: changing ownership of `/home/tim/src/tuxmath/build/bin/tuxmath':
> Operation not permitted
> make: *** [install] Error 1
>
> I edited the Makefile to allow me to set OWNER, and that works the first
> time. However, when I modify & recompile, then I get a different problem:
> it turns out that the install script also copies all the .svn directories
> (presumably, this is not actually desirable?) and on these directories I
> get permission errors (because these files are locked for writing even by
> the owner).
>
> Unfortunately, not being a C/C++ wiz I haven't had enough experience with
> Makefiles to solve this one easily myself. I tried putting in a
>      cp $(find . | grep -v ".svn") $(DATA_PREFIX)
> but I think make tries to interpret my shell command as a makefile
> variable. Anyone else know how to fix this? (Use rsync instead of cp? Or do
> some people not have that installed on their systems?)
>
> 3. In the configuration file, I've noticed that the ranges for subtraction
> are not specified as the complement of the addition problems---for that,
> one would specify "subtrahend" and "difference" rather than "minuend"
> and "subtrahend". This is in contrast with division, which is the
> complement of multiplication. One consequence is that kids get 121 addition
> problems if they go from 0 to 10, but many more subtraction problems that
> include 20-4=16 etc. This is not a bug, and may not even be bad, but it's
> something I noticed. I can try to help change it if that's desirable.
>
> Once again, thanks for a great program!
> --Tim Holy

Re: [Tuxmath-devel] Patches & plans for tuxmath

[David B. <db...@ta...>]

Hi Tim,

On Monday 28 August 2006 11:23, Tim Holy wrote:
> Hi,
>
> First and foremost, thanks to all the people who have contributed to
> tuxmath, making it a great program that my family is benefitting from a
> lot. Particular thanks Bill Kendrick for creating tuxmath and GPLing it,
> and to David Bruce for all the enhancements he's given it.

Thanks.

> Attached are two tiny enhancements:
> 1. (trivial) Provide a bit more description of what the play_through_list
> mode does---I kept trying to supply a text file for the problem list until
> I looked at the source code. The relevant patch file is mathcards.diff.
> This patch also adds a comment on a point that I initially found confusing.

Thanks - I have added these clarifications.  This just points up the ongoing 
need for better documentation, and the value of more eyeballs to point out 
things that are not clear.

> 2. On some systems (e.g., older, or perhaps even current, KDE systems using
> aRTs), sound hardware can be temporarily unavailable, because aRTs
> didn't/doesn't share the sound resources nicely. In that case, sound gets
> turned off. The problem is that this then gets saved as the user's
> preference for the next session.

I had also noticed this and fixed it in a slightly different way in the code 
currently on my computer.  Briefly, I also added another flag to the 
game_options struct which I called sound_available, which is not read or 
written to the config file.  I then added a brief accessor function, 
opts_using_sound(), which returns true only if both flags are true.  The rest 
of the program now uses this function instead of looking directly at 
game_options->use_sound.  It will be in the next svn commit.
>
> I'd also consider working on some more significant enhancements:
> 1. The options configuration screen doesn't reflect current reality all
> that well,

Agreed.  Once I get the config file reading and writing into a more general 
and flexible form, the options screen is due for a major overhaul.  It will 
be a lot of work to write an in-game options system capable of controlling 
every setting in the config file without some sort of widget set (e.g.Qt).  
The rewrite of 'options' will likely be a compromise.  After that, a Qt-based 
tuxmath-config standalone program might be on the agenda.
>
> Conversely, tuxmath is clearly to the point of being useful for classroom
> purposes---but there, a teacher might want to be able to prevent students
> from changing the assignments to "plus" when they're supposed to be working
> on "times." So, some method for allowing someone to set, say by a
> configuration file, which options should be "locked" (and not even show up
> on the options screen) could be a useful feature.

In progress.

>
> 2. It strikes me that a good way to control the pace of the game might be
> through feedback.

Sounds like a good idea.  Currently, the game offers several settings related 
to speed and the number of comets.  The default is for both to increase 
progressively, but this can be turned off by setting "allow_speedup" to 
false.  There is also "slow_after_wrong", which turns the speed and comet 
number down to the starting values if a comet hits a city.  Certainly, more 
dynamic or fine-grained adjustments could be implemented.


> 1. Please, the tuxmath web page and the sourceforge page should both point
> to the current subversion tree.

Definitely.  I've really only worked on the coding aspect, but I will try to 
contact these sites and fix this.

> 2. Installing: the PREFIX=?? syntax doesn't work for me unless I take root
> privileges. It complains about the "chown" (here are the last 4 lines of
> output):

> Unfortunately, not being a C/C++ wiz I haven't had enough experience with
> Makefiles to solve this one easily myself. I tried putting in a
>      cp $(find . | grep -v ".svn") $(DATA_PREFIX)
> but I think make tries to interpret my shell command as a makefile
> variable. Anyone else know how to fix this? (Use rsync instead of cp? Or do
> some people not have that installed on their systems?)

As others have pointed out, the make install target could be improved.  At 
least for now, I also don't know enough to feel very comfortable changing it.  
(I am a middle-aged surgeon and dad who is nearly completely self-taught with 
regard to programming - my last formal computer course was used Algol on 
punchcards in 1981).
>
> 3. In the configuration file, I've noticed that the ranges for subtraction
> are not specified as the complement of the addition problems---for that,
> one would specify "subtrahend" and "difference" rather than "minuend"
> and "subtrahend". This is in contrast with division, which is the
> complement of multiplication. One consequence is that kids get 121 addition
> problems if they go from 0 to 10, but many more subtraction problems that
> include 20-4=16 etc. This is not a bug, and may not even be bad, but it's
> something I noticed. I can try to help change it if that's desirable.

I see - setting the same operand ranges for addition and subtraction does not 
yield the same "math fact families", to us a term from my kid's text.
>
> Once again, thanks for a great program!
> --Tim Holy

Thanks for your detailed and thoughtful feedback!
-- 
David Bruce

Re: [Tuxmath-devel] [SPAM] Re: Patches & plans for tuxmath

[Tim H. <ho...@wu...>]

Hi David,

On Tuesday 29 August 2006 07:47, David Bruce wrote:
> > 2. On some systems (e.g., older, or perhaps even current, KDE systems
> > using aRTs), sound hardware can be temporarily unavailable, because aRTs
> > didn't/doesn't share the sound resources nicely. In that case, sound gets
> > turned off. The problem is that this then gets saved as the user's
> > preference for the next session.
>
> I had also noticed this and fixed it in a slightly different way in the
> code currently on my computer.  Briefly, I also added another flag to the
> game_options struct which I called sound_available, which is not read or
> written to the config file.  I then added a brief accessor function,
> opts_using_sound(), which returns true only if both flags are true.  The
> rest of the program now uses this function instead of looking directly at
> game_options->use_sound.  It will be in the next svn commit.

Sounds like a cleaner solution to me.

>
> > I'd also consider working on some more significant enhancements:
> > 1. The options configuration screen doesn't reflect current reality all
> > that well,
>
> Agreed.  Once I get the config file reading and writing into a more general
> and flexible form, the options screen is due for a major overhaul.  It will
> be a lot of work to write an in-game options system capable of controlling
> every setting in the config file without some sort of widget set (e.g.Qt).
> The rewrite of 'options' will likely be a compromise.  After that, a
> Qt-based tuxmath-config standalone program might be on the agenda.

I agree. It sounds like a scary project, and one of the main reasons I started 
with the feedback was that it seemed so much easier. GUI programming is not, 
sadly, a strength of mine.

> > 2. It strikes me that a good way to control the pace of the game might be
> > through feedback.
>
> Sounds like a good idea.  Currently, the game offers several settings
> related to speed and the number of comets.  The default is for both to
> increase progressively, but this can be turned off by setting
> "allow_speedup" to false.  There is also "slow_after_wrong", which turns
> the speed and comet number down to the starting values if a comet hits a
> city.  Certainly, more dynamic or fine-grained adjustments could be
> implemented.

Yes, those settings are indeed useful, and so at first I wasn't sure that 
implementing feedback would be necessary (in fact, it's not, as long as kids 
eventually get the ability to control the speedup through the improved 
options screen you described) or even helpful. But, it turned out to be quite 
easy to do. Furthermore, it occurs to me that my daughter's math skills will 
probably increase faster than her tolerance for danger, so having the speed 
adjust itself to achieve a fairly constant sense of danger might work well 
(at least for her). Similar considerations might apply to a room full of 2nd 
graders who have different math abilities.

> As others have pointed out, the make install target could be improved.  At
> least for now, I also don't know enough to feel very comfortable changing
> it. (I am a middle-aged surgeon and dad who is nearly completely
> self-taught with regard to programming - my last formal computer course was
> used Algol on punchcards in 1981).

I'm a neuroscientist who also hasn't taken a computer course since, oh, high 
school. We may be closer in our "real lives" than I would have expected. 
Certainly, I don't feel that I really know what I'm doing, I'm just hoping to 
make modest improvements to an already-great game for my kids.

Thanks again!
--Tim

Re: [Tuxmath-devel] Patches & plans for tuxmath

[Bill K. <nb...@so...>]

On Mon, Aug 28, 2006 at 10:23:47AM -0500, Tim Holy wrote:
> 1. Please, the tuxmath web page and the sourceforge page should both point to
> the current subversion tree. When I started hacking on it, I was going to use
> the CVS; but by chance I had first downloaded the sources from Debian 
> unstable, and was surprised to see that these seemed newer and more 
> featureful than the CVS. I then poked around and found the subversion tree, 
> but it could have easily worked out differently, wasting a bunch of time.

Is there a new _web_ page for Tux Math?  If so, I'm happy to point the
New Breed Software visitors to it.  Otherwise, I guess I'll just link to the
SVN tree and make a note that the current download links are of an older
version.

Thx!

-bill!

Re: [Tuxmath-devel] Patches & plans for tuxmath

[Tim H. <ho...@wu...>]

Hi Bill,

On Tuesday 29 August 2006 16:05, Bill Kendrick wrote:
> Otherwise, I guess I'll just link to
> the SVN tree and make a note that the current download links are of an
> older version.

If nothing better occurs, that seems like it would go a long way to solving 
the problem. Thanks!

--Tim

[Tuxmath-devel] tuxmath & -type hosting (Re: Patches & plans for tuxmath)

[Holger L. <de...@la...>]

Hi,

On Tuesday 29 August 2006 23:05, Bill Kendrick wrote:
> On Mon, Aug 28, 2006 at 10:23:47AM -0500, Tim Holy wrote:
> > 1. Please, the tuxmath web page and the sourceforge page should both
> > point to the current subversion tree. When I started hacking on it, I w=
as
> Is there a new _web_ page for Tux Math?  If so, I'm happy to point the
> New Breed Software visitors to it.  Otherwise, I guess I'll just link to
> the SVN tree and make a note that the current download links are of an
> older version.

Well, there used to be http://trac.tux4kids.net/tuxmath/browser - but trac =
is=20
currently down, the svn is still available I guess. Trac is really useful,=
=20
its a wiki and a request-tracker combined with a webinterface to svn. It wa=
s=20
set up for tuxmath and tuxtype (and linked from=20
http://layer-acht.org/debian/tuxmath/ and=20
http://layer-acht.org/debian/tuxtype/).=20

So I thought/think the trac-wiki could be the ideal place for a tux* homepa=
ge,=20
if it were there :-/

I just sent an email to Calvin, who hosts tux4kids.net. He had a network=20
outtage (and more trouble) due to a storm four weeks ago...

I'm not sure what to do, if Calvin thinks he can (and wants to) provide a=20
reliable service (sorry...!) in the future, or if we should look for other=
=20
alternatives. I'm certainly willing (and able) to help on the hosting side..


regards,
	Holger