tuxmath-devel — TuxMath developer's mailing list.

[Tuxmath-devel] Tu -- xmath commit problem resolved

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

Tuxmath colleagues:

It appears that for some reason Subversion has become more picky about 
the "https://" instead of "http://".  After I changed the url accordingly, 
the commit problem went away.

Anyway, tuxmath 0.93/revision 21 has now been committed, with improvements in 
config file handling and the ability to pass the name of a config file as a 
command line argument.

There will probably be another commit quite soon with a few other quick things 
I want to get in (Tim Holy's feedback speed regulation, answer formats on a 
per-operation basis as suggested by Yves Combe, more correct location of 
global config file, and maybe some other odds and ends).

Cheers.
-- 
David Bruce

[Tuxmath-devel] Tuxmath 0.93 commit - revision 21

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

Hi Holger et al,

I'm trying to commit the latest tuxmath to svn but have gotten the following 
error:

svn: Commit failed (details follow):
svn: COPY of src/fileops.c: 502 Bad Gateway (http://svn.tux4kids.net)

I am able to see the svn site on the web and do svn status and svn update OK.  
I have not changed anything with svn on my end (other than updating the svn 
software itself with apt-get) - any ideas?

Regarding tuxmath itself, the high points include better and more general 
handling of config files, including the "-optionfile filename" feature 
suggested by Yves.  There is also a fair amount of code reorganization 
involving setup().

Thanks for any ideas regarding svn.
-- 
David Bruce

Re: [Tuxmath-devel] guREP LICAza

[Dominica H. <ka...@dd...>]

=20
Best se t IIi l ng w g atc t hes
R h OLE a X
CA r RTI e ER
B v REITLIN c G
BV p LGAR x I
=20
and man k y othe t r at http://shorktpersonwithahair.com
O f rd z er T k od x ay and s g av h e.
=20

, a=20

, r=20

, c=20

, r=20

Mist rose and darkened the scene. It was the end.
remembered how Steengo had been buffing his own fingernails when he
as he pointed to my dissected clothing, bag, shoes.

[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

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

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

[Tuxmath-devel] [fwd] Tux, of math command (feature request)

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

I got this last month...

----- Forwarded message from Jeffrey Gordon -----

Date: Mon, 31 Jul 2006 17:11:34 -0700
From: Jeffrey Gordon <jeffreygordonchachacha AT yahoo com>
Subject: Tux, of math command (feature request)
To: bi...@ne...

Bill,

I don't know if you're still taking feature requests for "Tux, of math 
command", but I put one in asking you to change the number levels for 
the game.  Basically, they don't make that much sense.  I work at an 
academic learning center in Fremont, California and I installed Edubuntu 
on one of the desktops.  Tux of math command is a big hit with the kids, 
but because of the way the levels are set up, it doesn't match the math 
facts they're learning very well.  I explain it in greater detail at the 
feature request:

http://sourceforge.net/tracker/index.php?func=detail&aid=1532106&group_id=34443&atid=411031

Bottom line, it would be better if the levels were broken down: 1-5, 
6-10, 11-12, and 13-20.  The most important thing is to break it between 
10 and 11.

Thanks,
Jeffrey Gordon


----- End forwarded message -----

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

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] Tuxmath feedback on speed

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

Dear Tim,

On Tuesday 29 August 2006 11:40, Tim Holy wrote:
> Hi all,
>
> OK, I went ahead and implemented a rough draft of the feedback-based
> control of speed that I proposed yesterday. It's already to the point where
> you can use the .tuxmath file to enable feedback or not, and control
> various feedback-related parameters. I've tested it briefly on my kids, who
> at least didn't seem to think that the game had suddenly gotten worse, and
> might have even liked it better. Time will tell.
>
> If this is of interest, how should I submit it? It's not by any means a
> huge change, but it does touch several files in a number of places. I can
> submit patches (I've "corrupted" my original files, so any diffs will now
> include the patches I sent yesterday).

I guess you should just send the diffs to me and I'll look at them and try to 
work them in. My current source files have changed a fair amount since the 
last svn commit (mainly reworking setup.c and improving handling of config 
files).  Once I get your stuff merged in I'll do a fresh commit before 
starting anything else. 

>I am also a happy SVN user, if 
> anyone wants to give me SVN access... :-).

As I recall, the svn site is run by Sam Hart <sa...@sa...>.  

Thanks,

David Bruce

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

[Tuxmath-devel] Tuxmath feedback on speed

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

Hi all,

OK, I went ahead and implemented a rough draft of the feedback-based control 
of speed that I proposed yesterday. It's already to the point where you can 
use the .tuxmath file to enable feedback or not, and control various 
feedback-related parameters. I've tested it briefly on my kids, who at least 
didn't seem to think that the game had suddenly gotten worse, and might have 
even liked it better. Time will tell.

If this is of interest, how should I submit it? It's not by any means a huge 
change, but it does touch several files in a number of places. I can submit 
patches (I've "corrupted" my original files, so any diffs will now include 
the patches I sent yesterday). I am also a happy SVN user, if anyone wants to 
give me SVN access... :-).

If this does get incorporated, here are a few notes for testers:
1. Feedback is currently OFF by default. The best way to try it is to update 
your sources & recompile, run tuxmath one time, quit, and then edit 
your .tuxmath file to turn feedback on. (You won't see an option to turn 
feedback on until you've run this version once.)
2. Currently I've enabled FEEDBACK_DEBUG, so that testers receive output to 
see how the feedback is working. I highly recommend running in non-fullscreen 
mode so you can see this output while playing. (Hit 'p' to pause the game to 
study the feedback output after each wave is over.)
3. The .tuxmath file contains a few guidelines for choosing parameters related 
to feedback. Understand that, for the moment, these are just wild guesses on 
my part---the amount of "usability testing" has been rather small. :-)

Best,
--Tim

Re: [Tuxmath-devel] qinaRX

[Moritz W. <hal...@ce...>]

Hi,
G s ood news for you.
=20
PHA j RM t ACY d v irect t ly from the ma b nuf m act y urer,
Eco b nomi h ze up t a o 6 a 0 % w a ith us http://oplikitunhadwan.com

, f=20

, j=20

, e=20

Reasonable, Steengo said doubtfully. But what are we doing with
the photos?
Given to us when we were booted out of the place. Hints made of

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

[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] RXzaxa

[Mariamne C. <rad...@hr...>]

Hi,
Go o od news for you.
=20
PHA o RMA g CY di f rect b ly from the ma j nufa n ctur z er,
Eco b nomi f ze u x p to 60 x % wi s th us http://kolitunhertionter.com

, n=20

, p=20

, y=20

If the Paradisians were short on building materials they certainly
werent bereft of architectural imagination. Tall pill pillars capped
with ornate capitals, rose up to support the archive of a complex

Re: [Tuxmath-devel] Small Patch

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

Thanks Atief!

> I've been using TuxMath to teach my little bro how to calculate lately and
> it's been a huge success.
>
> I've been looking at the code and can't help thinking that the Max Answer
> and the Range for the operands somehow cancel eachother out, wouldn't it be
> better to be able to define just the operands freely and get the max answer
> as a result from them?
>
> Anyhow, i've made a little improvement on substraction in game.c, it
> removes a redundant loop. I hope you like it.

The code has changed a lot since the version you looked at.  Everything 
related to generation of math questions is now in two new files, mathcards.c 
and mathcards.h.  You can find the latest source at 
https://svn.tux4kids.net/tuxmath/.  
-- 
David Bruce

[Tuxmath-devel] Small Patch

[Afief H. <af...@gm...>]

Hey there,

I've been using TuxMath to teach my little bro how to calculate lately and
it's been a huge success.

I've been looking at the code and can't help thinking that the Max Answer
and the Range for the operands somehow cancel eachother out, wouldn't it be
better to be able to define just the operands freely and get the max answer
as a result from them?

Anyhow, i've made a little improvement on substraction in game.c, it removes
a redundant loop. I hope you like it.

Re: [Tuxmath-devel] Patch: Cleaner exit on error

[David Y. <hob...@gm...>]

On 8/23/06, Holger Levsen <de...@la...> wrote:
>
>
>
> I won't have time to test this (I guess you did...?)...


Glad to help :)

Yea, forgot to say: I tested it on Ubuntu Dapper using full screen and
window mode. (The segfault was present in window mode, even though it didn't
cause X problems.)


David

Re: [Tuxmath-devel] Patch: Cleaner exit on error

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

Hi David,

On Wednesday 23 August 2006 06:30, David Yoder wrote:
> Indeed the problem was there. tux_frame was not getting set for the path
> through the code in which <esc> is pressed before animation is done. I ju=
st
> initialized tux_frame.

w00t! Thank you!

I won't have time to test this (I guess you did...?) until next week, but i=
t's=20
great to have it :)


regards,
	Holger

Re: [Tuxmath-devel] Patch: Cleaner exit on error

[David Y. <hob...@gm...>]

On 8/21/06, David Yoder <hob...@gm...> wrote:
>
> 828                 SDL_BlitSurface(Tux[tux_frame], NULL, screen,
> &Tuxdest);
> (gdb) Fatal signal: Segmentation Fault (SDL Parachute Deployed)
>

Indeed the problem was there. tux_frame was not getting set for the path
through the code in which <esc> is pressed before animation is done. I just
initialized tux_frame.

David


tuxtype-dmysegfault.patch
====================


diff -urN tuxtype/branches/tuxtype1/tuxtype/graphics.c
tuxtype-dmysegfault/branches/tuxtype1/tuxtype/graphics.c
--- tuxtype/branches/tuxtype1/tuxtype/graphics.c        2006-08-22 23:06:
37.000000000 -0500
+++ tuxtype-dmysegfault/branches/tuxtype1/tuxtype/graphics.c    2006-08-22
23:06:13.000000000 -0500
@@ -329,7 +329,7 @@
                     back_h;
     int             i,
                     j,
-                    tux_frame;
+                    tux_frame = 1;
     int             x = 0;
     int             y = 0;
     int             dirx = 1;

Re: [Tuxmath-devel] Patch: Cleaner exit on error

[David Y. <hob...@gm...>]

On 8/21/06, Holger Levsen <de...@la... > wrote:
>
>
> As I could "reproduce" it (it just happens randomly, yay) recently, I
> won't
> close this one.
>

You didn't _say_ it was intermittent ;)

I pounded on keys for a while and can reliably reproduce a failure. By
pressing <esc> even once while the title screen ( standby.png) is showing or
while the menu screen is animating together, it segfaults. Sometimes I get:

Fatal signal: Segmentation Fault (SDL Parachute Deployed)

and X is returned to normal. Sometimes I get just a segfault message:

Segmentation fault

and X is pretty borked. Not just the resolution. The mouse is also
unresponsive. A <ctrl><alt><bksp> restores things.

The ratio of segfault with borked X to without borked X is 1:3 - 1:5 in my
very small sample. I haven't seen it fail the first time.

I am using:

Version: 1.0-5ubuntu on my nice shiny Dapper install with X.org xserver-xorg
version 7.0.0-0ubuntu45.
Latest in svn branches/tuxtype1 on my nice shiny Dapper install with
X.orgxserver-xorg version
7.0.0-0ubuntu45.
Version: 1.0-4 on my older Debian install with XFree86 xserver-xfree86
version 6.9.0.dsfg.1-4.

FWIW, these boxes both use nvidia 5200 cards with nvidia binary drivers.

A couple of interesting things

1) The latest tuxtype from svn trunk/tuxtype does not exhibit this failure

2) tuxmath does not exhibit this failure

3) I managed to catch it in gdb. It seems to be failing when the menu screen
is being written. Specifically when the tux animation is drawn.

(gdb) run
...
0x08055efb in TitleScreen (verbose=200) at graphics.c:828
828                 SDL_BlitSurface(Tux[tux_frame], NULL, screen, &Tuxdest);
(gdb) Fatal signal: Segmentation Fault (SDL Parachute Deployed)
...

A little closer.

David

Re: [Tuxmath-devel] Patch: Cleaner exit on error

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

Hi,

On Sunday 20 August 2006 03:50, David Yoder wrote:
> I couldn't find a working tuxtype list, so I'll just post here.

rights, it's down atm, I need to write mail about that...

> The fix I made to tuxmath is already present (perhaps in a more elegant
> way) in tuxtype. That is, calling SDL_Quit for all exits. In tuxtype it is
> done with atexit(). The bug report stated it was found in 1.0-4. I looked
> all the way back to CVS Tag 0.9 on the sourceforge CVS repository, and the
> same atexit(SDL_Quit) method is used everywhere I look.

Strange. I definitly had it happening with a recent version from svn - and =
I=20
know there where no relevant changes in svn since them.

> The version I installed with Ubuntu Dapper, 1.0, is working correctly
> (switches to a different resolution fullscreen, then switches back at
> exit).

Sometimes upon exit (also regular ones) the screen resolution is wrong.

> Being Dapper, my DSL libraries are newer than reported in the bug. And I
> don't have a clue what other than the X server is in the chain to change X
> resolution. So I'm not reproducing the exact case. But at least the probl=
em
> doesn't seem to be in tuxtype.

Though the last time it happened, it was with xfree86, not with xorg...

> In summary I couldn't reproduce the bug. I don't know what Debian's
> policies are on closing bugs that can't be reproduced (and are 3 years
> old).

As I could "reproduce" it (it just happens randomly, yay) recently, I won't=
=20
close this one.


regards & thanks anyway!
	Holger

Re: [Tuxmath-devel] Patch: Cleaner exit on error

[David Y. <hob...@gm...>]

Holger,

I couldn't find a working tuxtype list, so I'll just post here.

The fix I made to tuxmath is already present (perhaps in a more elegant way)
in tuxtype. That is, calling SDL_Quit for all exits. In tuxtype it is done
with atexit(). The bug report stated it was found in 1.0-4. I looked all the
way back to CVS Tag 0.9 on the sourceforge CVS repository, and the same
atexit(SDL_Quit) method is used everywhere I look.

The version I installed with Ubuntu Dapper, 1.0, is working correctly
(switches to a different resolution fullscreen, then switches back at exit).


Just to be sure I got the latest source of tuxtype2 from
https://svn.tux4kids.net/tuxtype/ and compiled. It exited normally with
<esc> and quit menu and by moving the images directory to cause an error
exit.

Being Dapper, my DSL libraries are newer than reported in the bug. And I
don't have a clue what other than the X server is in the chain to change X
resolution. So I'm not reproducing the exact case. But at least the problem
doesn't seem to be in tuxtype.

In summary I couldn't reproduce the bug. I don't know what Debian's policies
are on closing bugs that can't be reproduced (and are 3 years old).

David

On 8/19/06, Holger Levsen <de...@la...> wrote:
>
> Hi David,
>
> On Saturday 19 August 2006 07:56, David Yoder wrote:
> > I noticed that if I am running fullscreen and exit due to a failure to
> load
> > images, the screen resolution stays at 640x480. It's easy enough to
> change
> > it back, but annoying.
> >
> > So, I modified the exit on errors to cleanup a bit better. Now error
> exits
> > in setup.c call SDL_Quit and the other heap cleanup that was already
> > present on a normal exit. Except the first error exit because no heap
> space
> > allocation or SDL calls have been made at that point.
> >
> > I made the assumption that if exiting due to an error, you wouldn't want
> to
> > save the options to the configuration file.
>
> Great! Thanks a lot!
>
> Do you think you could "port" this patch to tuxtype as well? It has the
> same
> problem, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=217448
>
>
> regards,
>         Holger
>
>
> -------------------------------------------------------------------------
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job
> easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
>
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>
>
>
>

Re: [Tuxmath-devel] Patch: Cleaner exit on error

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

Dear David,

On Saturday 19 August 2006 01:56, David Yoder wrote:
>  Dave & All,
>
> Thanks for the great program!
>
> I just got a binary of a year old with Ubuntu, and wanted to slow things
> down a bit for a less advanced kiddo. I downloaded the latest from svn, and
> it was already there.
>
> I noticed that if I am running fullscreen and exit due to a failure to load
> images, the screen resolution stays at 640x480. It's easy enough to change
> it back, but annoying.
>
> So, I modified the exit on errors to cleanup a bit better. Now error exits
> in setup.c call SDL_Quit and the other heap cleanup that was already
> present on a normal exit. Except the first error exit because no heap space
> allocation or SDL calls have been made at that point.
>
> I made the assumption that if exiting due to an error, you wouldn't want to
> save the options to the configuration file.
>
>
> David

Thanks!  It will be in svn with my next commit.

-- 
David Bruce

Re: [Tuxmath-devel] Patch: Cleaner exit on error

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

Hi David,

On Saturday 19 August 2006 07:56, David Yoder wrote:
> I noticed that if I am running fullscreen and exit due to a failure to lo=
ad
> images, the screen resolution stays at 640x480. It's easy enough to change
> it back, but annoying.
>
> So, I modified the exit on errors to cleanup a bit better. Now error exits
> in setup.c call SDL_Quit and the other heap cleanup that was already
> present on a normal exit. Except the first error exit because no heap spa=
ce
> allocation or SDL calls have been made at that point.
>
> I made the assumption that if exiting due to an error, you wouldn't want =
to
> save the options to the configuration file.

Great! Thanks a lot!

Do you think you could "port" this patch to tuxtype as well? It has the sam=
e=20
problem, see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=3D217448


regards,
	Holger