tuxmath-devel — TuxMath developer's mailing list.

Re: [Tuxmath-devel] Finsihing up!

[David B. <dav...@gm...>]

Hi Brendan,

> *Get TuxMath merged into master--if this is okay with David, I haven't seen
> any instability in TuxMath.

The latest t4kcommon builds and installs fine for me.

Do you have any local changes on your machine that you haven't pushed
into tuxmath's commonification branch yet?  I get a flurry of
"undefined reference" errors with the autotools build.  If I build
with cmake, it builds without errors, but the resulting program exits
with an error:

dbruce@emperor:/usr/local/src/git/tuxmath/buildcmake$ tuxmath
Initializing Tux4Kids-Common 1.0.0
load_image(): ERROR could not load required graphics file menu/stop.svg
SDL: SDL_RWFromFile(): No file or no mode specified

Before I dive into either of these things too much, it would be nice
to know if they are just a matter of some work being only partially
committed (really "pushed", with git).

>TuxType is a different story.

When we get things more settled with tuxmath and t4kcommon, I plan to
spend some time "porting" tuxtype to t4kcommon.

> *Publish HTML docs--who's taking care of the website these days?

Me I guess, meaning really no one since about the beginning of GSoC.
If you mean putting them in the "Docs" section of our project on
Alioth (https://alioth.debian.org/docman/?group_id=31080), I can give
it a shot although I am only minimally familiar with that feature of
the site.

Best,

David

Re: [Tuxmath-devel] Finsihing up!

[Brendan L. <bm...@ri...>]

All,

I'm also going through some documentation, mostly for the API in
t4k_common.h, and *finally* getting some testing in on the ancient Mac.

Action items for the last few days:
*Get TuxMath merged into master--if this is okay with David, I haven't seen
any instability in TuxMath. TuxType is a different story.
*Publish HTML docs--who's taking care of the website these days?
*Include some automation for moving future functions out into the library.
Most likely, this will be another dumb Perl script :)

Best,
Brendan

On Sat, Aug 7, 2010 at 6:27 AM, Wenyuan Guo <guo...@gm...> wrote:

> Time sure flew! I'm off to complete my source documentation for
> changes I've made. Good luck to everyone!
>
> Wenyuan
>
> On Sat, Aug 7, 2010 at 3:39 AM, Brendan Luchen <bm...@ri...> wrote:
> > Hi Tim,
> >
> > On Fri, Aug 6, 2010 at 6:29 AM, Tim Holy <ho...@wu...> wrote:
> >>
> >> On Thursday, August 05, 2010 09:32:18 pm you wrote:
> >> > I look forward to testing the improvements!
> >> >
> >> >  Why wait :)? Take a look now, and tell me if there are any gaping
> holes
> >> > to
> >> > plug up before focusing on documentation and--well--testing. But yes,
> >> > time
> >> > sure has flown. I should be tying up all the major stuff by tomorrow.
> I
> >> > hope.
> >>
> >> Good point! It seems I've been waiting to check master---I'm still
> clunky
> >> on
> >> git, I guess, and don't always notice updates in other branches (how the
> >> heck
> >> do you know that there are things waiting to be pulled?). But I just
> >> switched
> >> to commonification, and it plays well! At the user level, one way I
> >> noticed
> >> that it's improved over master is that on the "campaign" modes it
> doesn't
> >> dump
> >> a whole lot of text to the console. I did notice a bit:
> >>
> >> Entering start_campaign()
> >> Stage cadet
> >> Round 1
> >> Starting game...
> >>
> >> and that could presumably be put under our "debug" infrastructure, but
> >> it's
> >> much, much less than master currently dumps. And I did not notice any
> >> disadvantages to commonification.
> >
> >
> > What a pleasant surprise! There was one disadvantage, and a big one:
> sprite
> > caching wasn't working properly due to the dimensions being read
> > incorrectly. But I think I've nailed that one. Much earlier than I
> expected,
> > too. At this point, I'm ready to call it stable, if there aren't any more
> > subtle bugs hiding, and move on to tidying things up as per SoC
> guidelines.
> > The campaign could definitely use an update or two. I don't think it's
> been
> > touched for over a year (certainly not since Bolek put in the sweet
> > debugging system), barring the quick fix a couple of weeks ago. I'll make
> a
> > note to give it some TLC.
> > Best,
> > Brendan
> >
> ------------------------------------------------------------------------------
> > This SF.net email is sponsored by
> >
> > Make an app they can't live without
> > Enter the BlackBerry Developer Challenge
> > http://p.sf.net/sfu/RIM-dev2dev
> > _______________________________________________
> > Tuxmath-devel mailing list
> > Tux...@li...
> > https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
> >
> >
>

[Tuxmath-devel] Instructions for testing Tuxmath and Tuxtype in schoolmode

[Vikas S. <vik...@gm...>]

Hello

It was a great summer and I agree with Tim, Brendan and Wenyuan regarding
their theory of time moving fast during summers :) !
Finally I am wrapping up things.

The steps for testing Tuxtype in schoolmode are

1. Get the schoolmode branch

$ git clone git+ssh://vik...@gi.../git/tux4kids/tuxmath.git
$ git fetch origin
$git checkout  -b schoolmode origin/schoolmode
$git pull

2. Compile the code.

3. A sample lesson file lessonData.xml is provided with tuxtype in
tuxtype/data/lessondata.xml

4. Create a folder for mission files.Suppose  its name is "mission" with two
subdirectories mission/new/  and mission/old/

5. Copy the lessonData.xml file in the directory  mission/new/   using
   $ sleep 30 ; cp lessonData.xml   /home/vikas/mission/new/

Note : The above procedure is adopted because the tuxtype game can be run
and made to wait for lesson file (as earlier proposed by Michal)
to be created by teacher using Tux4kids-admin program.
It searches the mission/new/ directory for lessonData.xml file every 10
seconds and as soon as it finds it, it loads tuxtype in schoolmode by
parsing that lesson file.

6. Run the game as
$ tuxtype --schoolmode path_to_mission_directory
  path_to_mission_directory in my case is  /home/vikas/mission/.

7. Result file will be saved after game is over.


Similar instructions are for Tuxmath except the sample lesson lessonData.xml
file is located in tuxmath/data/images/schoolmode/lessonData.xml


-- 
Regards ,
Vikas Singh

Re: [Tuxmath-devel] Finsihing up!

[Wenyuan G. <guo...@gm...>]

Time sure flew! I'm off to complete my source documentation for
changes I've made. Good luck to everyone!

Wenyuan

On Sat, Aug 7, 2010 at 3:39 AM, Brendan Luchen <bm...@ri...> wrote:
> Hi Tim,
>
> On Fri, Aug 6, 2010 at 6:29 AM, Tim Holy <ho...@wu...> wrote:
>>
>> On Thursday, August 05, 2010 09:32:18 pm you wrote:
>> > I look forward to testing the improvements!
>> >
>> >  Why wait :)? Take a look now, and tell me if there are any gaping holes
>> > to
>> > plug up before focusing on documentation and--well--testing. But yes,
>> > time
>> > sure has flown. I should be tying up all the major stuff by tomorrow. I
>> > hope.
>>
>> Good point! It seems I've been waiting to check master---I'm still clunky
>> on
>> git, I guess, and don't always notice updates in other branches (how the
>> heck
>> do you know that there are things waiting to be pulled?). But I just
>> switched
>> to commonification, and it plays well! At the user level, one way I
>> noticed
>> that it's improved over master is that on the "campaign" modes it doesn't
>> dump
>> a whole lot of text to the console. I did notice a bit:
>>
>> Entering start_campaign()
>> Stage cadet
>> Round 1
>> Starting game...
>>
>> and that could presumably be put under our "debug" infrastructure, but
>> it's
>> much, much less than master currently dumps. And I did not notice any
>> disadvantages to commonification.
>
>
> What a pleasant surprise! There was one disadvantage, and a big one: sprite
> caching wasn't working properly due to the dimensions being read
> incorrectly. But I think I've nailed that one. Much earlier than I expected,
> too. At this point, I'm ready to call it stable, if there aren't any more
> subtle bugs hiding, and move on to tidying things up as per SoC guidelines.
> The campaign could definitely use an update or two. I don't think it's been
> touched for over a year (certainly not since Bolek put in the sweet
> debugging system), barring the quick fix a couple of weeks ago. I'll make a
> note to give it some TLC.
> Best,
> Brendan
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by
>
> Make an app they can't live without
> Enter the BlackBerry Developer Challenge
> http://p.sf.net/sfu/RIM-dev2dev
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>
>

Re: [Tuxmath-devel] Finsihing up!

[Brendan L. <bm...@ri...>]

Hi Tim,

On Fri, Aug 6, 2010 at 6:29 AM, Tim Holy <ho...@wu...> wrote:

> On Thursday, August 05, 2010 09:32:18 pm you wrote:
> > I look forward to testing the improvements!
> >
> >  Why wait :)? Take a look now, and tell me if there are any gaping holes
> to
> > plug up before focusing on documentation and--well--testing. But yes,
> time
> > sure has flown. I should be tying up all the major stuff by tomorrow. I
> > hope.
>
> Good point! It seems I've been waiting to check master---I'm still clunky
> on
> git, I guess, and don't always notice updates in other branches (how the
> heck
> do you know that there are things waiting to be pulled?). But I just
> switched
> to commonification, and it plays well! At the user level, one way I noticed
> that it's improved over master is that on the "campaign" modes it doesn't
> dump
> a whole lot of text to the console. I did notice a bit:
>
> Entering start_campaign()
> Stage cadet
> Round 1
> Starting game...
>
> and that could presumably be put under our "debug" infrastructure, but it's
> much, much less than master currently dumps. And I did not notice any
> disadvantages to commonification.
>


What a pleasant surprise! There was one disadvantage, and a big one: sprite
caching wasn't working properly due to the dimensions being read
incorrectly. But I think I've nailed that one. Much earlier than I expected,
too. At this point, I'm ready to call it stable, if there aren't any more
subtle bugs hiding, and move on to tidying things up as per SoC guidelines.

The campaign could definitely use an update or two. I don't think it's been
touched for over a year (certainly not since Bolek put in the sweet
debugging system), barring the quick fix a couple of weeks ago. I'll make a
note to give it some TLC.

Best,
Brendan

[Tuxmath-devel] Finsihing up!

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

Hi everyone,

This is the last official week of GSoC. Wow, has time flown! If you haven't 
already done so, now is the time to really try to finish off things you're 
working on now and get the patches committed.

I look forward to testing the improvements!

Best,
--Tim

Re: [Tuxmath-devel] Migration chugging along nicely

[Wenyuan G. <guo...@gm...>]

Hi Brendan,

>  I did notice, while looking through get_svg_dimensions(), that it calls
> rsvg_init() and rsvg_term(). I'm not familiar with RSVG but I'd expect those
> to be meant to be called once per run. Do you think that might be the reason
> for the bottleneck in getting SVG dimensions?

This must be programmer's common instinct. I noticed this quirk too.
But unfortunately (fortunately maybe?), this two calls are
instantaneous according to my tests :).

Cheers
Wenyuan

Re: [Tuxmath-devel] Migration chugging along nicely

[Brendan L. <che...@gm...>]

Hey Wenyuan,

Thanks for taking a look!



> 1. t4k_menu.c: when user press F10, you need to resize both the title
> screen and menu items. Currently "T4K_PrerenderAll" doesn't seem to
> resize title screen. You probably need to hook up with the appropriate
> function in "titlescreen.c" (or your equivalent in t4kcommon).
>

Right, I think we want to keep a separation between the titlescreen
(generally, game-specific stuff) and the actual menu. So it's taken care of
in HandleTitleScreenResSwitch() in titlescreen.c. This function is called
directly by HandleTitleScreenEvents() but should probably be a separate
callback passed to T4K_RunMenu().

I should have pushed all the changes necessary for this (at least) to work
right. Does it still look funky on your end?


> 2. t4k_loaders.c: you don't seem to have SVG sprites prerender code
> yet. Just for your reference, this feature is implemented in
> "load_sprite" function of "loaders.c" in tuxmath. Migrating it ought
> not to be an issue.
>

Ah, good catch. Sweet!

 I did notice, while looking through get_svg_dimensions(), that it calls
rsvg_init() and rsvg_term(). I'm not familiar with RSVG but I'd expect those
to be meant to be called once per run. Do you think that might be the reason
for the bottleneck in getting SVG dimensions?

Best,
Brendan

Re: [Tuxmath-devel] Migration chugging along nicely

[David B. <dav...@gm...>]

Hi Brendan,



> I'm trying not to be too invasive with my changes in TuxMath, but I fear in
> order to do this "the right way" most of the variables in question will have
> to be removed from TuxMath and the routines that use them largely rewritten.
> More on this story as it develops.
>
> As soon as it's stable, I'd like to do one more testing push before focusing
> on merging. I don't want to recklessly jump into it, but at the same time,
> I'm anxious (even with git) that the longer it waits, the more painful it
> will be.

At this point, I'd be inclined to make libt4kcommon a mandatory part
of tuxmath and start removing the duplicated variables and functions.
As for merging, it may just boil down to saying "commonification is
the new master" once we are confident that Wenyuan's work over the
summer has been merged into or replicated in commonification.

Best,

David

Re: [Tuxmath-devel] Migration chugging along nicely

[Wenyuan G. <guo...@gm...>]

Hi Brendan,

After checking through t4kcommon, I found,

1. t4k_menu.c: when user press F10, you need to resize both the title
screen and menu items. Currently "T4K_PrerenderAll" doesn't seem to
resize title screen. You probably need to hook up with the appropriate
function in "titlescreen.c" (or your equivalent in t4kcommon).

2. t4k_loaders.c: you don't seem to have SVG sprites prerender code
yet. Just for your reference, this feature is implemented in
"load_sprite" function of "loaders.c" in tuxmath. Migrating it ought
not to be an issue.

3. I couldn't find your version of "game.c" of tuxmath yet: there was
also a bug I fixed in that file, i.e. when user presses F10, only the
game itself but not the title screen and menu items were resized,
leading to clipped screen when user returned to menu. You might want
to check that one out when converting it to your common lib.

The others seem to be in order. This integration stuff is pretty nasty
job. Please feel free to ask away if you need clarification!

Cheers
Wenyuan

On Thu, Jul 29, 2010 at 6:06 AM, Brendan Luchen <che...@gm...> wrote:
> Hi all,
> After migrating (hopefully) the last few duplicate functions in TuxMath,
> I've jumped into the more messy work. I've been bringing in Wenyuan's
> work--by hand, unfortunately, since I don't see a way to apply diffs from
> one repo into the other, and if there were, it probably wouldn't work
> correctly anyway. Basically, I'm reading through his diffs in TuxMath and
> making appropriate changes in libt4k_common. Wenyuan, would you mind looking
> through my recent commits[0] and making sure I didn't miss something of
> yours?
> As I work through the SVG stuff, I'm adapting things here and there and
> fixing some small issues I come across. The bigger issues, I'm not even
> touching. One such big issue (I don't remember whether I've mentioned
> before) is the fact that T4K_RunMenu handles the event loop and resolution
> switches, but allows the game to affect the run via several callbacks, such
> as drawing and handling events. What's missing is a callback for when
> resolution changes--for now, there's a hack in the event callback that
> checks for a F_10 keypress, assumes (correctly) that the switch is taken
> care of already, and proceeds to recalculate the size and position for Tux
> and other game-specific things.
> I'm thick into testing at this moment. Everything behaves on Ubuntu; On
> Fedora, gdb reports that something is funky with relocation, but is able to
> recover; under MinGW, there are a whole bunch of unpredictable behaviors
> that I believe stem from extern'd variables that are defined in both the
> library and TuxMath--for example, the infamous "SDL_Surface* screen". So
> TuxMath-centric code may accidentally access libt4k_common variables, and
> vice versa. This is particularly hard to debug because AFAIK there's no way
> to tell which module a symbol is coming from, other than educated guesses.
> I'm trying not to be too invasive with my changes in TuxMath, but I fear in
> order to do this "the right way" most of the variables in question will have
> to be removed from TuxMath and the routines that use them largely rewritten.
> More on this story as it develops.
>
> As soon as it's stable, I'd like to do one more testing push before focusing
> on merging. I don't want to recklessly jump into it, but at the same time,
> I'm anxious (even with git) that the longer it waits, the more painful it
> will be.
>
> One thing I'd forgotten is that after the dust has settled, I wanted to put
> some sort of utility in place to automate factoring out functions into the
> library The rationale is that down the road, even if we're no longer sharing
> code directly between TM and TT, it might be too easy to let duplicate
> functionality build up if it's a chore to add new exciting things to
> libt4k_common. Then whenever someone does undertake to do the refactoring,
> things break and there is weeping and gnashing of teeth.
> Phew! Sorry for the long-winded rambling, but it's been a busy few days. If
> any of this is unclear, I'll happily elucidate. I'm just excited to be
> actually coding again :)
>
> [0] http://git.debian.org/?p=tux4kids/t4kcommon.git;a=summary
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>
>

Re: [Tuxmath-devel] [Tux4kids-tuxtype-dev] zh_TW.po for git version

[Frank W. (a.k.a. Franklin) <fra...@go...>]

Hi David,

Thanks for your reply.  We'll see what we can do for tuxtype.

However, about tuxmath, it did not work.  I tried "LANGUAGE=zh tuxmath", 
"LANGUAGE=zh_CN tuxmath", "LANGUAGE=zh_TW tuxmath", and even "LANGUAGE=it 
tuxmath" it all showed English.  (Of course I have put the mo file into the 
locale directory.  However, is the path of mo files tuxmath would read at 
/usr/share/locale/zh_TW/LC_MESSAGES?)

And, does tuxmath recognize the locale as "zh" or "zh_CN" and "zh_TW"?  Under 
zh locale, we have zh_CN(for China), zh_TW(for Taiwan), zh_HK(for Hong Kong), 
and so on.  zh_TW and zh_HK are using traditional Chinese but their wording 
are different, while zh_CN is using simplified Chinese.

So if tuxmath only recognizes "zh", should I issue a bug report and request 
the developer to split the zh into different locales?

By the way, did you accept the zh_TW.po for tuxmath and tuxtype?


Thanks,
Franklin

在 週四 29 七月 2010 00:52:57，您寫道:
> Hi Frank,
> 
> On Wed, Jul 28, 2010 at 2:32 AM, Frank Weng (a.k.a. Franklin)
> 
> <fra...@go...> wrote:
> > Hi list,
> > 
> > Here is the translation of zh_TW translations.  I've merged it with
> > current git version tuxtype.pot.
> > 
> > However I have a problem.  When I tried our own translation, I put the
> > tuxtype.mo to /usr/share/locale/zh_TW/LC_MESSAGES/.  However, it still
> > did not show any Chinese characters.  It was still in English.  Is the
> > path correct? In the Mandriva package, the other languages mo files were
> > put in the /usr/share/locale.  However even if I used
> 
> The problem is that tuxtype still relies on the locale being set
> within the program when the user selects a theme.  It does not use the
> system locale as determined by environmental variables.  This is
> something we need to fix.
> 
> Until we get the above issue fixed, I think you could get tuxtype to
> display the menus in Chinese by creating a Chinese theme (look at some
> of the other themes under data/themes) and having a line in the
> settings.txt file such as:
> 
> theme_locale_name=zh_TW.UTF-8
> 
> 
> (assuming the po file is encoded in UTF-8).
> 
> 
> 
> That still leaves the issue of Chinese character input, which I am
> pretty sure tuxtype is not able to handle as things currently stand.
> For that, we started to move the input methods code from tuxpaint into
> tuxtype, but that work is not finished.
> 
> In summary, tuxtype doesn't yet support i18n nearly as well as it
> ought to, but we are aware of the issues.
> 
> As for tuxmath, it should work.  Tuxmath does follow the environmental
> variables, so something like "LANGUAGE=zh tuxmath" on the command line
> ought to set the language to display Chinese, as long as you have a
> locale installed corresponding to "zh".  Also, tuxmath relies on
> SDL_Pango for display of non-Western characters, so you need to have
> SDL_Pango enabled (which has been our default for a long time).
> 
> 
> Hope that helps, and thanks for the feedback,
> 
> David Bruce
> 
> 
> btw - for reasons I don't understand, setting the LANG variable (e.g.
> "LANG=zh tuxmath") doesn't work, but setting LANGUAGE does - perhaps
> LANGUAGE overrides LANG if both are found in the shell environment.

Re: [Tuxmath-devel] Migration chugging along nicely

[Wenyuan G. <guo...@gm...>]

Hi Brendan,

Great! I will go checkout your commits and let you know if anything is
missing for my part.

Cheers
Wenyuan

On Thu, Jul 29, 2010 at 6:06 AM, Brendan Luchen <che...@gm...> wrote:
> Hi all,
> After migrating (hopefully) the last few duplicate functions in TuxMath,
> I've jumped into the more messy work. I've been bringing in Wenyuan's
> work--by hand, unfortunately, since I don't see a way to apply diffs from
> one repo into the other, and if there were, it probably wouldn't work
> correctly anyway. Basically, I'm reading through his diffs in TuxMath and
> making appropriate changes in libt4k_common. Wenyuan, would you mind looking
> through my recent commits[0] and making sure I didn't miss something of
> yours?
> As I work through the SVG stuff, I'm adapting things here and there and
> fixing some small issues I come across. The bigger issues, I'm not even
> touching. One such big issue (I don't remember whether I've mentioned
> before) is the fact that T4K_RunMenu handles the event loop and resolution
> switches, but allows the game to affect the run via several callbacks, such
> as drawing and handling events. What's missing is a callback for when
> resolution changes--for now, there's a hack in the event callback that
> checks for a F_10 keypress, assumes (correctly) that the switch is taken
> care of already, and proceeds to recalculate the size and position for Tux
> and other game-specific things.
> I'm thick into testing at this moment. Everything behaves on Ubuntu; On
> Fedora, gdb reports that something is funky with relocation, but is able to
> recover; under MinGW, there are a whole bunch of unpredictable behaviors
> that I believe stem from extern'd variables that are defined in both the
> library and TuxMath--for example, the infamous "SDL_Surface* screen". So
> TuxMath-centric code may accidentally access libt4k_common variables, and
> vice versa. This is particularly hard to debug because AFAIK there's no way
> to tell which module a symbol is coming from, other than educated guesses.
> I'm trying not to be too invasive with my changes in TuxMath, but I fear in
> order to do this "the right way" most of the variables in question will have
> to be removed from TuxMath and the routines that use them largely rewritten.
> More on this story as it develops.
>
> As soon as it's stable, I'd like to do one more testing push before focusing
> on merging. I don't want to recklessly jump into it, but at the same time,
> I'm anxious (even with git) that the longer it waits, the more painful it
> will be.
>
> One thing I'd forgotten is that after the dust has settled, I wanted to put
> some sort of utility in place to automate factoring out functions into the
> library The rationale is that down the road, even if we're no longer sharing
> code directly between TM and TT, it might be too easy to let duplicate
> functionality build up if it's a chore to add new exciting things to
> libt4k_common. Then whenever someone does undertake to do the refactoring,
> things break and there is weeping and gnashing of teeth.
> Phew! Sorry for the long-winded rambling, but it's been a busy few days. If
> any of this is unclear, I'll happily elucidate. I'm just excited to be
> actually coding again :)
>
> [0] http://git.debian.org/?p=tux4kids/t4kcommon.git;a=summary
>
> ------------------------------------------------------------------------------
> The Palm PDK Hot Apps Program offers developers who use the
> Plug-In Development Kit to bring their C/C++ apps to Palm for a share
> of $1 Million in cash or HP Products. Visit us here for more details:
> http://p.sf.net/sfu/dev2dev-palm
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>
>

[Tuxmath-devel] Migration chugging along nicely

[Brendan L. <che...@gm...>]

Hi all,

After migrating (hopefully) the last few duplicate functions in TuxMath,
I've jumped into the more messy work. I've been bringing in Wenyuan's
work--by hand, unfortunately, since I don't see a way to apply diffs from
one repo into the other, and if there were, it probably wouldn't work
correctly anyway. Basically, I'm reading through his diffs in TuxMath and
making appropriate changes in libt4k_common. Wenyuan, would you mind looking
through my recent commits[0] and making sure I didn't miss something of
yours?

As I work through the SVG stuff, I'm adapting things here and there and
fixing some small issues I come across. The bigger issues, I'm not even
touching. One such big issue (I don't remember whether I've mentioned
before) is the fact that T4K_RunMenu handles the event loop and resolution
switches, but allows the game to affect the run via several callbacks, such
as drawing and handling events. What's missing is a callback for when
resolution changes--for now, there's a hack in the event callback that
checks for a F_10 keypress, assumes (correctly) that the switch is taken
care of already, and proceeds to recalculate the size and position for Tux
and other game-specific things.

I'm thick into testing at this moment. Everything behaves on Ubuntu; On
Fedora, gdb reports that something is funky with relocation, but is able to
recover; under MinGW, there are a whole bunch of unpredictable behaviors
that I believe stem from extern'd variables that are defined in both the
library and TuxMath--for example, the infamous "SDL_Surface* screen". So
TuxMath-centric code may accidentally access libt4k_common variables, and
vice versa. This is particularly hard to debug because AFAIK there's no way
to tell which module a symbol is coming from, other than educated guesses.
I'm trying not to be too invasive with my changes in TuxMath, but I fear in
order to do this "the right way" most of the variables in question will have
to be removed from TuxMath and the routines that use them largely rewritten.
More on this story as it develops.

As soon as it's stable, I'd like to do one more testing push before focusing
on merging. I don't want to recklessly jump into it, but at the same time,
I'm anxious (even with git) that the longer it waits, the more painful it
will be.

One thing I'd forgotten is that after the dust has settled, I wanted to put
some sort of utility in place to automate factoring out functions into the
library The rationale is that down the road, even if we're no longer sharing
code directly between TM and TT, it might be too easy to let duplicate
functionality build up if it's a chore to add new exciting things to
libt4k_common. Then whenever someone does undertake to do the refactoring,
things break and there is weeping and gnashing of teeth.

Phew! Sorry for the long-winded rambling, but it's been a busy few days. If
any of this is unclear, I'll happily elucidate. I'm just excited to be
actually coding again :)

[0] http://git.debian.org/?p=tux4kids/t4kcommon.git;a=summary

Re: [Tuxmath-devel] [Tux4kids-tuxtype-dev] zh_TW.po for git version

[David B. <dav...@gm...>]

Hi Frank,

On Wed, Jul 28, 2010 at 2:32 AM, Frank Weng (a.k.a. Franklin)
<fra...@go...> wrote:
> Hi list,
>
> Here is the translation of zh_TW translations.  I've merged it with current
> git version tuxtype.pot.
>
> However I have a problem.  When I tried our own translation, I put the
> tuxtype.mo to /usr/share/locale/zh_TW/LC_MESSAGES/.  However, it still did not
> show any Chinese characters.  It was still in English.  Is the path correct?
> In the Mandriva package, the other languages mo files were put in the
> /usr/share/locale.  However even if I used

The problem is that tuxtype still relies on the locale being set
within the program when the user selects a theme.  It does not use the
system locale as determined by environmental variables.  This is
something we need to fix.

Until we get the above issue fixed, I think you could get tuxtype to
display the menus in Chinese by creating a Chinese theme (look at some
of the other themes under data/themes) and having a line in the
settings.txt file such as:

theme_locale_name=zh_TW.UTF-8


(assuming the po file is encoded in UTF-8).



That still leaves the issue of Chinese character input, which I am
pretty sure tuxtype is not able to handle as things currently stand.
For that, we started to move the input methods code from tuxpaint into
tuxtype, but that work is not finished.

In summary, tuxtype doesn't yet support i18n nearly as well as it
ought to, but we are aware of the issues.

As for tuxmath, it should work.  Tuxmath does follow the environmental
variables, so something like "LANGUAGE=zh tuxmath" on the command line
ought to set the language to display Chinese, as long as you have a
locale installed corresponding to "zh".  Also, tuxmath relies on
SDL_Pango for display of non-Western characters, so you need to have
SDL_Pango enabled (which has been our default for a long time).


Hope that helps, and thanks for the feedback,

David Bruce


btw - for reasons I don't understand, setting the LANG variable (e.g.
"LANG=zh tuxmath") doesn't work, but setting LANGUAGE does - perhaps
LANGUAGE overrides LANG if both are found in the shell environment.

[Tuxmath-devel] zh_TW.po for git version

[Frank W. (a.k.a. Franklin) <fra...@go...>]

Hi list,

Here is the translation of zh_TW translations.  I've merged it with current 
git version tuxmath.pot.

However I have a problem.  When I tried our own translation, I put the 
tuxmath.mo to /usr/share/locale/zh_TW/LC_MESSAGES/.  However, it still did not 
show any Chinese characters.  It was still in English.  Is the path correct?  
In the Mandriva package, the other languages mo files were put in the 
/usr/share/locale.  However even if I used

LC_ALL=it tuxmath

It still showed English.  Where will tuxmath read the language mo files?

Thanks,
Franklin

Re: [Tuxmath-devel] Further performance improvement with more caching mechanisms

[Wenyuan G. <guo...@gm...>]

Hi Brendan,

On Mon, Jul 26, 2010 at 12:45 AM, Brendan Luchen <bm...@ri...> wrote:
>> I agree that this is probably the best thing to do now. Certainly it seems
>> likely that loading times will increase as you have more images. If that
>> becomes problematic, one obvious solution would be to defer loading of
>> images
>> that are not needed immediately (e.g., menu items only when you need them,
>> comets game images only when you need them, etc.).
>
>
> My 2 cents: lazy loading might actually create the illusion of slowness,
> since the loads would be during program use. IMO, if everything can be
> loaded quickly enough for us to "hide" it behind the Tux4Kids logo, that's
> best.

I think you are right! Actually in the worst case, we may create a
low-priority thread that loads things aren't needed immediately, while
allowing the main program to proceed as soon as it is ready.

Wenyuan

Re: [Tuxmath-devel] Further performance improvement with more caching mechanisms

[Brendan L. <bm...@ri...>]

>
> I agree that this is probably the best thing to do now. Certainly it seems
> likely that loading times will increase as you have more images. If that
> becomes problematic, one obvious solution would be to defer loading of
> images
> that are not needed immediately (e.g., menu items only when you need them,
> comets game images only when you need them, etc.).
>


My 2 cents: lazy loading might actually create the illusion of slowness,
since the loads would be during program use. IMO, if everything can be
loaded quickly enough for us to "hide" it behind the Tux4Kids logo, that's
best.

Re: [Tuxmath-devel] Further performance improvement with more caching mechanisms

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

Hi Wenyuan,

On Friday, July 23, 2010 07:31:56 pm Wenyuan Guo wrote:
> Tim: should I move onto PNG -> SVG conversion phase, now that we have
> achieved most of our objectives of program optimization? It might be
> interesting to see what problems may occur as more images are in SVG.
> What is your opinion?

I agree that this is probably the best thing to do now. Certainly it seems 
likely that loading times will increase as you have more images. If that 
becomes problematic, one obvious solution would be to defer loading of images 
that are not needed immediately (e.g., menu items only when you need them, 
comets game images only when you need them, etc.). But assuming that's not 
already implemented, it seems sensible to first try the straightforward "just 
load everything" and see how long it takes; if it's too long, then deal with 
the issues when you can profile and see where the bottlenecks are.

Exciting!
--Tim

> 
> Cheers
> Wenyuan
> 
> On Fri, Jul 23, 2010 at 9:06 AM, David Bruce <dav...@gm...> 
wrote:
> > Hi,
> > 
> >> Has anyone else tried the new program? Any feedback is most welcome!
> > 
> > I built it just now on my home desktop and it works great.  I also
> > built and ran it on a Dell Mini 9 (a much slower machine), and also
> > had excellent results.  The first execution has a few seconds of
> > delay, but after that the program responds quite quickly both at
> > startup and change of resolution.
> > 
> > Hooray!
> > 
> > On a completely unrelated note, I noticed one build pitfall that is
> > triggered if the same build directory is used for a CMake build and
> > then an autotools build - CMake puts config.h under src, whereas
> > autoheader puts config.h directly into the build directory.  The
> > problem is that they don't create  equivalent files, and the CMake
> > version shows up first in the include path, so a subsequent autotools
> > build doesn't find the correct config.h.  This leads to an compile
> > error the first time something from config.h is needed, in this case
> > PACKAGE.
> > 
> > The moral of the story is that when testing both build systems, keep
> > each in its own build directory.
> > 
> > David

Re: [Tuxmath-devel] Further performance improvement with more caching mechanisms

[Wenyuan G. <guo...@gm...>]

Hi David,

Glad to hear about your experiment results! It is great to know that
the program runs smoothly on older machines too.

Tim: should I move onto PNG -> SVG conversion phase, now that we have
achieved most of our objectives of program optimization? It might be
interesting to see what problems may occur as more images are in SVG.
What is your opinion?

Cheers
Wenyuan

On Fri, Jul 23, 2010 at 9:06 AM, David Bruce <dav...@gm...> wrote:
> Hi,
>
>> Has anyone else tried the new program? Any feedback is most welcome!
>
> I built it just now on my home desktop and it works great.  I also
> built and ran it on a Dell Mini 9 (a much slower machine), and also
> had excellent results.  The first execution has a few seconds of
> delay, but after that the program responds quite quickly both at
> startup and change of resolution.
>
> Hooray!
>
> On a completely unrelated note, I noticed one build pitfall that is
> triggered if the same build directory is used for a CMake build and
> then an autotools build - CMake puts config.h under src, whereas
> autoheader puts config.h directly into the build directory.  The
> problem is that they don't create  equivalent files, and the CMake
> version shows up first in the include path, so a subsequent autotools
> build doesn't find the correct config.h.  This leads to an compile
> error the first time something from config.h is needed, in this case
> PACKAGE.
>
> The moral of the story is that when testing both build systems, keep
> each in its own build directory.
>
> David
>

Re: [Tuxmath-devel] Further performance improvement with more caching mechanisms

[David B. <dav...@gm...>]

Hi,

> Has anyone else tried the new program? Any feedback is most welcome!

I built it just now on my home desktop and it works great.  I also
built and ran it on a Dell Mini 9 (a much slower machine), and also
had excellent results.  The first execution has a few seconds of
delay, but after that the program responds quite quickly both at
startup and change of resolution.

Hooray!

On a completely unrelated note, I noticed one build pitfall that is
triggered if the same build directory is used for a CMake build and
then an autotools build - CMake puts config.h under src, whereas
autoheader puts config.h directly into the build directory.  The
problem is that they don't create  equivalent files, and the CMake
version shows up first in the include path, so a subsequent autotools
build doesn't find the correct config.h.  This leads to an compile
error the first time something from config.h is needed, in this case
PACKAGE.

The moral of the story is that when testing both build systems, keep
each in its own build directory.

David

Re: [Tuxmath-devel] Further performance improvement with more caching mechanisms

[Wenyuan G. <guo...@gm...>]

Hi Tim,

Thank you for the compliments! Although things didn't go exactly as
expected, I'm just quite happy and relieved that the new problems
could be easily solved and the performance boost I promised earlier
can be delivered.

Has anyone else tried the new program? Any feedback is most welcome!

Cheers
Wenyuan

On Thu, Jul 22, 2010 at 8:50 AM, Tim Holy <ho...@wu...> wrote:
> Hi Wenyuan,
>
> This is good, careful work. I think your willingness to change your plans is
> admirable, and the half-second delay seems very livable, a big improvement on
> the previous 2s. Long live profiling! :-).
>
> Best,
> --Tim
>
> On Wednesday, July 21, 2010 06:26:11 pm Wenyuan Guo wrote:
>> Hi all,
>>
>> With more careful profiling of the program, I found my earlier theory
>> to be wrong: I thought the delay when switching resolution mainly came
>> from HDD delay. This component turns out to be minor, thanks to OS
>> caching. The following two components are much more significant:
>>
>> 1. Surprisingly, the librsvg function that determines the dimension of
>> an input SVG image file takes substantial time. I had thought that it
>> ought to be as simple as to locate the relevant strings from the SVG
>> file involving only minimum parsing efforts. In any case, I have build
>> an in-memory caching table to store dimensions of SVG files seen
>> before to minimize this performance penalty to once per file for each
>> session.
>>
>> 2. The PNG function to parse input file into SDL surface is the second
>> contributor to the delay, although smaller than 1. I have built
>> another in-memory caching mechanism for these SDL surfaces, with
>> reference copying instead of actual data copying. This assumes that
>> all loaded SDL surfaces are never modified, which seem to be the case
>> for tuxmath. This is faster and more memory efficient.
>>
>> With the additional caching, pressing F10 to switch resolution takes
>> only 0.5s, compared with about 2s before. Given this small delay, I
>> have scratched the multithreading mechanism implemented before, which
>> is no longer necessary. Moreover, the multithreading functions still
>> have mysterious bugs. There are too many rendering functions that have
>> global variable and I/O conflicts. It is extremely difficult to
>> identify all race conditions between them at this point.
>>
>> Cheers
>> Wenyuan
>>
>> ---------------------------------------------------------------------------
>> --- This SF.net email is sponsored by Sprint
>> What will you do first with EVO, the first 4G phone?
>> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
>> _______________________________________________
>> Tuxmath-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>

Re: [Tuxmath-devel] Further performance improvement with more caching mechanisms

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

Hi Wenyuan,

This is good, careful work. I think your willingness to change your plans is 
admirable, and the half-second delay seems very livable, a big improvement on 
the previous 2s. Long live profiling! :-).

Best,
--Tim

On Wednesday, July 21, 2010 06:26:11 pm Wenyuan Guo wrote:
> Hi all,
> 
> With more careful profiling of the program, I found my earlier theory
> to be wrong: I thought the delay when switching resolution mainly came
> from HDD delay. This component turns out to be minor, thanks to OS
> caching. The following two components are much more significant:
> 
> 1. Surprisingly, the librsvg function that determines the dimension of
> an input SVG image file takes substantial time. I had thought that it
> ought to be as simple as to locate the relevant strings from the SVG
> file involving only minimum parsing efforts. In any case, I have build
> an in-memory caching table to store dimensions of SVG files seen
> before to minimize this performance penalty to once per file for each
> session.
> 
> 2. The PNG function to parse input file into SDL surface is the second
> contributor to the delay, although smaller than 1. I have built
> another in-memory caching mechanism for these SDL surfaces, with
> reference copying instead of actual data copying. This assumes that
> all loaded SDL surfaces are never modified, which seem to be the case
> for tuxmath. This is faster and more memory efficient.
> 
> With the additional caching, pressing F10 to switch resolution takes
> only 0.5s, compared with about 2s before. Given this small delay, I
> have scratched the multithreading mechanism implemented before, which
> is no longer necessary. Moreover, the multithreading functions still
> have mysterious bugs. There are too many rendering functions that have
> global variable and I/O conflicts. It is extremely difficult to
> identify all race conditions between them at this point.
> 
> Cheers
> Wenyuan
> 
> ---------------------------------------------------------------------------
> --- This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel

[Tuxmath-devel] Further performance improvement with more caching mechanisms

[Wenyuan G. <guo...@gm...>]

Hi all,

With more careful profiling of the program, I found my earlier theory
to be wrong: I thought the delay when switching resolution mainly came
from HDD delay. This component turns out to be minor, thanks to OS
caching. The following two components are much more significant:

1. Surprisingly, the librsvg function that determines the dimension of
an input SVG image file takes substantial time. I had thought that it
ought to be as simple as to locate the relevant strings from the SVG
file involving only minimum parsing efforts. In any case, I have build
an in-memory caching table to store dimensions of SVG files seen
before to minimize this performance penalty to once per file for each
session.

2. The PNG function to parse input file into SDL surface is the second
contributor to the delay, although smaller than 1. I have built
another in-memory caching mechanism for these SDL surfaces, with
reference copying instead of actual data copying. This assumes that
all loaded SDL surfaces are never modified, which seem to be the case
for tuxmath. This is faster and more memory efficient.

With the additional caching, pressing F10 to switch resolution takes
only 0.5s, compared with about 2s before. Given this small delay, I
have scratched the multithreading mechanism implemented before, which
is no longer necessary. Moreover, the multithreading functions still
have mysterious bugs. There are too many rendering functions that have
global variable and I/O conflicts. It is extremely difficult to
identify all race conditions between them at this point.

Cheers
Wenyuan

Re: [Tuxmath-devel] Multithreading for rescaling title screen and menu items

[David B. <dav...@gm...>]

Hi,

> Yep, SDL is pretty good at doing that so we don't have to :) I thought
> the pthreads code for the LAN game "just works" so I didn't even
> mention it, but so much the better if it stands to benefit as well.
> AFAIK it's a bit more involved than the rendering thread--are we doing
> anything "fancy" that might not be available from SDL?

I have to look back at it, but basically I'm pretty sure I didn't do
anything fancy, as it was the first and only time I have used
pthreads.  Initially, tuxmathserver was written solely as a standalone
program.  To run it in a thread, I made almost the entire contents of
tuxmathserver's main() into a function called RunServer(), which could
then be either called from the thread or wrapped in a minimal main()
function to run on its own.

This all still needs some work - one big issue is that the code isn't
really thread-safe in two main ways.  First, the data in mathcards.c
isn't thread-safe, as the question list and related variables are
limited to a single instance.  Second, if the server function in the
thread exits, it calls MC_EndGame(), as well as SDLNet_Quit(), which
brings down tuxmath itself.  If Joao Moriera had decided to work on
tuxmath instead of tuxpaint, it would have been his GSoC project to
straighten out these problems.


Best,

David

Re: [Tuxmath-devel] Multithreading for rescaling title screen and menu items

[Brendan L. <che...@gm...>]

Hi all,

> If SDL threads do what we need, we might as well just go with that.
> It will make our code cleaner if we can avoid a bunch of #ifdef
> HAVE_PTHREADS or #ifdef WIN32 conditionals to handle cross-platform
> differences.

Yep, SDL is pretty good at doing that so we don't have to :) I thought
the pthreads code for the LAN game "just works" so I didn't even
mention it, but so much the better if it stands to benefit as well.
AFAIK it's a bit more involved than the rendering thread--are we doing
anything "fancy" that might not be available from SDL?

-Brendan