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
>
>