tuxmath-devel — TuxMath developer's mailing list.

Re: [Tuxmath-devel] Some updates

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

Hi Tim,

Thanks for the input.


> However, I did notice a performance problem that might be more severe: if the
> user hits F10 to toggle between full-screen and windowed modes, it takes time
> (~2s?) for the window to update. Furthermore, its substantially longer if the
> cache has not been populated at this resolution before. Interestingly, this
> only happens in the "menu" code; the game switches essentially instantly,
> presumably because that code isn't using the new loader.
>

Pressing F10 will require scaling of all menu sprites to the new
resolution. It used to take like 5s without caching. Now it roughly
takes 1-2s. But you have spotted a bug too! I tested the program and
indeed it is instantaneous when switching in-game. The reason is that
it doesn't scale the menu items. As a result, if you then quit the
game and return to the menu, all sprites will still be as big as in
fullscreen mode, resulted in a clipped screen. I suspect this bug was
present in the older versions too, i.e. before SVG caching was
introduced. I will look into it.

Cheerz
Wenyuan

Re: [Tuxmath-devel] Some updates

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

Hi Wenyuan,

I've now tried it on my laptop, which is 3 or 4 years old (I forget...). It's 
still about 2s on my machine, so I'm not that worried about it on machines of 
this caliber.

However, I did notice a performance problem that might be more severe: if the 
user hits F10 to toggle between full-screen and windowed modes, it takes time 
(~2s?) for the window to update. Furthermore, its substantially longer if the 
cache has not been populated at this resolution before. Interestingly, this 
only happens in the "menu" code; the game switches essentially instantly, 
presumably because that code isn't using the new loader.

Finally, as more of the graphics get moved over to SVG, I imagine that the 
delay could grow even longer. So now I'm back to thinking that perhaps your 
plan to have the graphics render in a separate thread is probably worth the 
effort.

Best,
--Tim

On Monday, July 05, 2010 10:55:25 pm Wenyuan Guo wrote:
> Hi folks,
> 
> > For a developer who might be testing tuxmath many times a day, a 2s delay
> > could become annoying. But I bet for a kid who might just launch it once
> > per day, that's probably a reasonable amount of time to devote to
> > "branding." So overall I would vote that additional optimization is not
> > necessary. Anybody feel differently?
> 
> I guess that's why I was annoyed with it at the first place, having
> sometimes to launch the program a dozen times in a short span :=). But
> it might be true that for a regular user, the 2s may not be that
> repulsive.
> 
> > Maybe we should try to test this on an old, low-powered machine to see
> > if it takes longer than 2s on such hardware.  If so, it would be
> > worthwhile to try to further optimize it.
> > 
> > As for shortening the "splash" time to less than 2s, it might be nice
> > to get it down to 1s or so, but I would consider it to be a low
> > priority.
> 
> I thought about this too. I don't have an old machine lying around
> right now. Anyone can chip in on how the program performs on their
> machines if they are relatively outdated? I suspect the main factor is
> the speed of harddisk, compound by the large number of files
> necessitating repositioning of the read head and a seek delay penalty
> for each file, compared with a large continuous file.  I think we can
> decide on whether to optimize it any further based on that.
> 
> 
> Wenyuan

Re: [Tuxmath-devel] Some updates

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

Hi folks,

> For a developer who might be testing tuxmath many times a day, a 2s delay
> could become annoying. But I bet for a kid who might just launch it once per
> day, that's probably a reasonable amount of time to devote to "branding." So
> overall I would vote that additional optimization is not necessary. Anybody
> feel differently?

I guess that's why I was annoyed with it at the first place, having
sometimes to launch the program a dozen times in a short span :=). But
it might be true that for a regular user, the 2s may not be that
repulsive.


> Maybe we should try to test this on an old, low-powered machine to see
> if it takes longer than 2s on such hardware.  If so, it would be
> worthwhile to try to further optimize it.
>
> As for shortening the "splash" time to less than 2s, it might be nice
> to get it down to 1s or so, but I would consider it to be a low
> priority.

I thought about this too. I don't have an old machine lying around
right now. Anyone can chip in on how the program performs on their
machines if they are relatively outdated? I suspect the main factor is
the speed of harddisk, compound by the large number of files
necessitating repositioning of the read head and a seek delay penalty
for each file, compared with a large continuous file.  I think we can
decide on whether to optimize it any further based on that.


Wenyuan

Re: [Tuxmath-devel] Some updates

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

Hi,

> Hmm, an interesting question. I think if we want to have the logo display for
> 2s, then I agree there is little point in further optimization, since you've
> gotten the loading time down below that. I guess the key question is whether
> we want to have the logo there for 2s.
>
> For a developer who might be testing tuxmath many times a day, a 2s delay
> could become annoying. But I bet for a kid who might just launch it once per
> day, that's probably a reasonable amount of time to devote to "branding." So
> overall I would vote that additional optimization is not necessary. Anybody
> feel differently?

Maybe we should try to test this on an old, low-powered machine to see
if it takes longer than 2s on such hardware.  If so, it would be
worthwhile to try to further optimize it.

As for shortening the "splash" time to less than 2s, it might be nice
to get it down to 1s or so, but I would consider it to be a low
priority.

David

Re: [Tuxmath-devel] Some updates

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

Hi Wenyan,

On Saturday, July 03, 2010 10:24:48 pm Wenyuan Guo wrote:
> I've been profiling the game to accelerate the startup sequence
> further, since the last update with SVG caches. In particular, I
> wanted to hide the remaining menu loading latency in a worker thread
> that runs parallel to the starting title animation (when "tux of math
> command" slides nicely across the screen). This turns out to be
> impossible/unnecessary after a closer examination of "titlescreen.c".
> Basically, there is a section of startup code there that locks us for
> at least 2 seconds at the logo screen, polling ESC press from the
> user. Presumably the program gives the user a grace period should he
> want to quit. In addition, my profiling suggests that the total time
> for menu loading and other initializations, after the last caching
> optimization, only takes 1.4 seconds (on my machine). That is to say
> that this latency is entirely hidden within the compulsory wait period
> already. As long as we do not change that section of code, there is no
> more acceleration possible for the startup sequence (that is, 2
> seconds at minimum).
> 
> My question is what is your experience with the current startup
> process of tuxmath. I know the performance and experience may differ
> from one machine to another. Or perhaps we can eliminate that
> compulsory ESC polling period and do multithreading for menu loading
> in favor of faster startup?  Or maybe there is no more need for
> further optimization and I should move on to the next phase of the
> project? What is your opinion?

Hmm, an interesting question. I think if we want to have the logo display for 
2s, then I agree there is little point in further optimization, since you've 
gotten the loading time down below that. I guess the key question is whether 
we want to have the logo there for 2s.

For a developer who might be testing tuxmath many times a day, a 2s delay 
could become annoying. But I bet for a kid who might just launch it once per 
day, that's probably a reasonable amount of time to devote to "branding." So 
overall I would vote that additional optimization is not necessary. Anybody 
feel differently?

Best,
--Tim

Re: [Tuxmath-devel] [Tux4kids-tuxtype-dev] Tar-zip library

[Akash G. <aka...@gm...>]

Hi Jesus,


On Sat, Jul 3, 2010 at 3:59 AM, Jesus Mager <fo...@gm...> wrote:

> Hi david (and all)!
>
> Thank you. I want to write code that can read a campaign file for
> tuxhistory. This file should be a compressed file that contains map
> files, lua scripts, etc... Mainly I need a transparent access to this
> files (I don't need inflate the files in a directory) to load the
> content in to memory. I was searching, but cant find any good resource
> to do that with zlib. I found a very good article [1], but it only
> shows a transparent access for one compressed file using zlib. The
> same text illustrates a good way to access multiple files using
> zzip[2]. Even though the library seems to be written in ANSI-C some
> comments specifics multiplaform/cross compiling problems. Any idea to
> deal this issue?
>
> [1] http://www.kekkai.org/roger/sdl/rwops/rwops.html
> [2] http://zziplib.sourceforge.net/
>
> 2010/6/30 David Bruce <dav...@gm...>:
> > Hi,
> >
> > On Wed, Jun 30, 2010 at 11:40 AM, Jesus Mager <fo...@gm...> wrote:
> >> Hi all!
> >>
> >> I'm trying to find a good way to compress and inflate the campaing
> >> files that should contain things like XML files, and in the future LUA
> >> and other text files. I was thinking zlib is a good option
> >
> > I take it you want to save space on the user's HD?  Obviously, our
> > tarballs and installer files are already compressed.
> >
> > Anyway, zlib is definitely cross-platform and is already part of our
> > dependencies (IIRC, SDL_image depends on zlib).  Thus, if it does what
> > needs to be done, you can use it without worrying about having to drag
> > in additional libs.  If that is what you do, we should add a test in
> > configure.ac to directly test for it, just so we still know that it is
> > available even if a future version of SDL_image no longer uses it.
> >
> > Cheers,
> >
> > David
> >
>
>
>
> --
> Jesus Mager
> [www.h1n1-al.blogspot.com]
>
> _______________________________________________
> Tux4kids-tuxtype-dev mailing list
> Tux...@li...
> http://lists.alioth.debian.org/mailman/listinfo/tux4kids-tuxtype-dev
>


Won't it work if I make two objects similarly instead of one, that's what
they
seem to have done with zziplib.

#include "SDL.h"
#include <stdio.h>
#include <zlib.h>

int main(void) {
  SDL_Surface *screen;
  SDL_Surface *one;
  SDL_Rect rect;

  /* This is the RWops structure we'll be using */
  SDL_RWops *rw;

  /* gzFile is the Zlib equivalent of FILE from stdio */
  gzFile file;

  /* We'll be needing space to store our graphic into.  The penguin
     graphic is about 12k, so we'll fake it for now.  You'd want to
     figure out how much space you need for other graphics in a real
     application, though. */
  Uint8 buffer[13000];

  /* We'll need to store the actual size of the file when it comes in
   */
  int filesize;

  SDL_Init(SDL_INIT_VIDEO);

  atexit(SDL_Quit);

  screen = SDL_SetVideoMode(640, 480, 16, SDL_DOUBLEBUF);

  /* Opens up the file with Zlib */
  file = gzopen("penguin.gz", "r");

  /*Your 2nd compressed file here*/

  file2 = gzopen("number2.gz", "r");

  /* Decompresses the file into memory (the buffer we set aside),
     13000 bytes max.  gzread returns the number of (decompressed)
     bytes it actually read, and we need that information for
     later. */
  filesize = gzread(file, buffer, 13000);

  filesize2 = gzread(file2, buffer, 13000);

/* Gives us an RWops from memory - SDL_RWFromMem needs to know where the
data is, and how big it is (thus why we saved the filesize) */ rw =
SDL_RWFromMem(buffer, filesize);

  rw2 = SDL_RWFromMem(buffer, filesize2);

/* The function that does the loading doesn't change at all */ one =
SDL_LoadBMP_RW(rw, 0);

  two = SDL_LoadBMP_RW(rw2, 0);

/* And clean up */ SDL_FreeRW(rw); gzclose(file); /* Haphazard way of
getting stuff to the screen */ rect.x = rect.y = 20; rect.w = one -> w;
rect.y = one -> h; SDL_BlitSurface(one, NULL, screen, &rect);


  rect.x += rect.w + 10;
  rect.w = two -> w;
  rect.h = two -> h;
  SDL_BlitSurface(two, NULL, screen, &rect);


SDL_Flip(screen); SDL_Delay(3000); }




-- 
Best Regards
Akash Gangil

[Tuxmath-devel] Some updates

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

Hi all,

Firstly a quick bug fix report: While I was playing around with the
program, I found a bug that causes tuxmath to crash (segfault) if the
user clicks on the STOP button when picking a lesson for hosting a LAN
game. The program didn't expect this behavior and would still try to
print out the returned lesson string and crash. Now it will simply
cancel the LAN game hosting attempt and return to the upper level
menu.

I've been profiling the game to accelerate the startup sequence
further, since the last update with SVG caches. In particular, I
wanted to hide the remaining menu loading latency in a worker thread
that runs parallel to the starting title animation (when "tux of math
command" slides nicely across the screen). This turns out to be
impossible/unnecessary after a closer examination of "titlescreen.c".
Basically, there is a section of startup code there that locks us for
at least 2 seconds at the logo screen, polling ESC press from the
user. Presumably the program gives the user a grace period should he
want to quit. In addition, my profiling suggests that the total time
for menu loading and other initializations, after the last caching
optimization, only takes 1.4 seconds (on my machine). That is to say
that this latency is entirely hidden within the compulsory wait period
already. As long as we do not change that section of code, there is no
more acceleration possible for the startup sequence (that is, 2
seconds at minimum).

My question is what is your experience with the current startup
process of tuxmath. I know the performance and experience may differ
from one machine to another. Or perhaps we can eliminate that
compulsory ESC polling period and do multithreading for menu loading
in favor of faster startup?  Or maybe there is no more need for
further optimization and I should move on to the next phase of the
project? What is your opinion?

Cheers
Wenyuan

Re: [Tuxmath-devel] Tar-zip library

[Jesus M. <fo...@gm...>]

Hi david (and all)!

Thank you. I want to write code that can read a campaign file for
tuxhistory. This file should be a compressed file that contains map
files, lua scripts, etc... Mainly I need a transparent access to this
files (I don't need inflate the files in a directory) to load the
content in to memory. I was searching, but cant find any good resource
to do that with zlib. I found a very good article [1], but it only
shows a transparent access for one compressed file using zlib. The
same text illustrates a good way to access multiple files using
zzip[2]. Even though the library seems to be written in ANSI-C some
comments specifics multiplaform/cross compiling problems. Any idea to
deal this issue?

[1] http://www.kekkai.org/roger/sdl/rwops/rwops.html
[2] http://zziplib.sourceforge.net/

2010/6/30 David Bruce <dav...@gm...>:
> Hi,
>
> On Wed, Jun 30, 2010 at 11:40 AM, Jesus Mager <fo...@gm...> wrote:
>> Hi all!
>>
>> I'm trying to find a good way to compress and inflate the campaing
>> files that should contain things like XML files, and in the future LUA
>> and other text files. I was thinking zlib is a good option
>
> I take it you want to save space on the user's HD?  Obviously, our
> tarballs and installer files are already compressed.
>
> Anyway, zlib is definitely cross-platform and is already part of our
> dependencies (IIRC, SDL_image depends on zlib).  Thus, if it does what
> needs to be done, you can use it without worrying about having to drag
> in additional libs.  If that is what you do, we should add a test in
> configure.ac to directly test for it, just so we still know that it is
> available even if a future version of SDL_image no longer uses it.
>
> Cheers,
>
> David
>



-- 
Jesus Mager
[www.h1n1-al.blogspot.com]

Re: [Tuxmath-devel] libt4k_common update

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

Hey David,

> It isn't even a case of the events having
> the wrong Unicode value - they don't get picked up at all.  I am at a
> complete loss for what might be going on here.

That makes two of us. On my end, *something* was being picked
up--every time I typed a letter, the buzzer would signal an incorrect
letter--but now that I'm actively looking for the bug, it seems to
have magically fixed itself. Keep your eyes peeled for random changes
in behavior; this looks like a more interesting bug than usual.

I think you're right about changing the calls the old-fashioned way.
The preprocessor abuse has been leading to more headaches than it
solves, because if I have a #define without changing or removing the
implementation of the function, that implementation gets preprocessed
as well and is picked up anyway. If I'm not mistaken, I haven't pushed
any of it (to either branch) yet. So, I'll just stash that away and go
back to square one. So much wasted time this week :(

Best,
Brendan

Re: [Tuxmath-devel] libt4k_common update

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

Hi Brendan,

>> I did recently notice that input bug in TuxType; I wasn't sure whether
>> it was only in my branch, because AFAIK the library doesn't have
>> anything input-related, and if it does, it's certainly not being used.
>> The source code hasn't really changed much at all, TBH. Oh, well, more
>> fun to debug.

Any progress figuring out what the deal is with keyboard input in the
tuxtype commonification branch?  I've been looking at it for the last
couple hours with some debugging printf()s, and something really
baffling is going on here.  In the "while (SDL_PollEvent(&event))"
loop at line 255, no keydown events get received for presses of
regular letter keys, punctuation, or anything else *except* Esc and
F10, which work correctly.  It isn't even a case of the events having
the wrong Unicode value - they don't get picked up at all.  I am at a
complete loss for what might be going on here.

The master branch works fine.

So, unless you have been able to figure something out, I think we may
need to start the "commonification" branch of tuxtype over with a much
smaller divergence from master.  Maybe just link in libt4k without
actually calling any libt4k functions, for starters, then migrate one
function at a time to libt4k.  Also, I wonder if the preprocessor
renaming might be triggering some unexpected side effects.  Perhaps,
if we see that a "#define foo_bar T4K_foo_bar" creates a bug, we could
instead go back and manually put in the T4K's until we see when the
bug occurs.

Anyway, good work overall!

David

Re: [Tuxmath-devel] Tar-zip library

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

Hi,

On Wed, Jun 30, 2010 at 11:40 AM, Jesus Mager <fo...@gm...> wrote:
> Hi all!
>
> I'm trying to find a good way to compress and inflate the campaing
> files that should contain things like XML files, and in the future LUA
> and other text files. I was thinking zlib is a good option

I take it you want to save space on the user's HD?  Obviously, our
tarballs and installer files are already compressed.

Anyway, zlib is definitely cross-platform and is already part of our
dependencies (IIRC, SDL_image depends on zlib).  Thus, if it does what
needs to be done, you can use it without worrying about having to drag
in additional libs.  If that is what you do, we should add a test in
configure.ac to directly test for it, just so we still know that it is
available even if a future version of SDL_image no longer uses it.

Cheers,

David

[Tuxmath-devel] Tar-zip library

[Jesus M. <fo...@gm...>]

Hi all!

I'm trying to find a good way to compress and inflate the campaing
files that should contain things like XML files, and in the future LUA
and other text files. I was thinking zlib is a good option... Any
other way to do this, or any other good library for this? I was
googling and i found libtar but the documentarion is really bad and
may be it is not multi-platform.

-- 
Jesus Mager
[www.h1n1-al.blogspot.com]

Re: [Tuxmath-devel] libt4k_common update

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

Hi Brendan,

> Okay, I thought that might be the case. My only fear is that the
> changes I'm making are so drastic that they might be difficult to
> merge afterwards; but it'd definitely be nice to keep master stable
> for a change ;) I won't push anything, then.

To elaborate a bit, by all means push your work into the server's
"commonification" branch as you go - the value of having remote
branches is that we all can look at what has been done and contribute.

You should periodically check "master" to see if anything has gone in
since you branched off.  You should start each session with a "git
pull", which IIRC by default will pull in updates for all of your
local branches that are tracking remote (i.e. server-resident)
branches.  If "master" has changed, you can pull the new commits into
"commonification" by doing "git merge master" while you have
"commonification" checked out.  Or, to be careful, you can scrutinize
the new commits with "git diff" and drag in the ones you want, one at
a time, with "git cherry-pick <COMMIT SHA>".   If you keep
"commonification" up to date in this way, then when it is time to
merge back into "master" it should be conflict-free.

As for merging work from "commonification" back into "master", don't
really worry about it for now.  I think the key thing there that once
you have merged commits into your local checkout of "master", do some
testing to be sure everything works before pushing them into "master"
at Alioth.

> I did recently notice that input bug in TuxType; I wasn't sure whether
> it was only in my branch, because AFAIK the library doesn't have
> anything input-related, and if it does, it's certainly not being used.
> The source code hasn't really changed much at all, TBH. Oh, well, more
> fun to debug.

At least when I checked last night, it was only in the
"commonification" branch.  I didn't look to see what is different in
that branch, other than linking to libt4k - that is, I don't know
which of the lib functions are getting called instead of tuxtype's own
functions.  From what little checking I did with some debugging
statements, it seems that the SDL_KEYDOWN events aren't being received
in the main Fish Cascade game loop.

Best,

David

Re: [Tuxmath-devel] libt4k_common update

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

Hi David,

>> -Brendan, who will now proceed to drop several bombs on TuxType's master branch
>
> All joking aside, please don't push anything into the master branches
> that breaks them.  I don't want to repeat last year, where tuxmath was
> sort of borked from early summer until late fall.

Okay, I thought that might be the case. My only fear is that the
changes I'm making are so drastic that they might be difficult to
merge afterwards; but it'd definitely be nice to keep master stable
for a change ;) I won't push anything, then.

I did recently notice that input bug in TuxType; I wasn't sure whether
it was only in my branch, because AFAIK the library doesn't have
anything input-related, and if it does, it's certainly not being used.
The source code hasn't really changed much at all, TBH. Oh, well, more
fun to debug.

-Brendan

Re: [Tuxmath-devel] libt4k_common update

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

Hi Brendan

> -Brendan, who will now proceed to drop several bombs on TuxType's master branch

All joking aside, please don't push anything into the master branches
that breaks them.  I don't want to repeat last year, where tuxmath was
sort of borked from early summer until late fall.  In the case of
"commonification", the more pertinent thing will be to periodically
merge "master" into "commonification" to keep your branch updated.
Or, if anyone makes a commit into "master", you can then just do a
"git cherry-pick" for that commit while on commonification to pull it
into the branch.

My hope with the switch to git is that we can keep the master branches
continuously building and running correctly.

Fortunately, I see you have made a "commonification" branch for
tuxtype.  On my machine, it builds and installs fine, and locates
libt4k appropriately, but it doesn't work at run-time - keyboard input
isn't recognized properly in the Fish Cascade, Comet Zap, and Phrase
Practice activities, although the keys seem to work OK for navigating
the menus.  Not sure what the issue is - but I guess it is a sign that
work is taking place ;)

Cheers,

David

Re: [Tuxmath-devel] libt4k_common update

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

> By the way, is "loaders.c" currently factored out in your common lib?

Yup. src/t4k-loaders.c is the file you want to look at.
git clone git://git.debian.org/git/tux4kids/t4kcommon.git t4k_common

-Brendan, who will now proceed to drop several bombs on TuxType's master branch

Re: [Tuxmath-devel] libt4k_common update

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

Great! That should only involve minimum change to the current source
code. Wouldn't cause a pain at merging time.

By the way, is "loaders.c" currently factored out in your common lib?
That's the module I've been working on most recently. I think
eventually it would be nice to integrate those into your library when
it is trimmed and made cross-project friendly (currently it has a few
tuxmath specific data structures and functions).

Wenyuan

On Sat, Jun 26, 2010 at 2:28 AM, Brendan Luchen <che...@gm...> wrote:
>> This is temporary, I take it?  I would assume that once we take the
>> plunge and commit ourselves to consistently using libt4k, we will go
>> back and change the function calls themselves.
>
> Right, there's no sense in abusing the CPP when the dust has settled.
> The same goes for the function declarations in t4k_common.h
>
> -Brendan
>

Re: [Tuxmath-devel] libt4k_common update

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

> This is temporary, I take it?  I would assume that once we take the
> plunge and commit ourselves to consistently using libt4k, we will go
> back and change the function calls themselves.

Right, there's no sense in abusing the CPP when the dust has settled.
The same goes for the function declarations in t4k_common.h

-Brendan

Re: [Tuxmath-devel] libt4k_common update

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

Hi,


>
> What I've been doing so far is using the preprocessor
> to redirect the calls instead of manually adding T4K all over the
> place. Here's an example from SDL_extras.h in TuxMath's
> commonification branch
>
> #ifndef HAVE_LIBT4K_COMMON
> void            DrawButton(SDL_Rect* target_rect, int radius, Uint8 r,
> Uint8 g, Uint8 b, Uint8 a);
> #else
> # define DrawButton T4K_DrawButton
> #endif
>

This is temporary, I take it?  I would assume that once we take the
plunge and commit ourselves to consistently using libt4k, we will go
back and change the function calls themselves.

David

Re: [Tuxmath-devel] libt4k_common update

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

Wenyuan,

> Just a quick question: when we eventually move to use libt4k_common
> with tuxmath, what changes do we need to make to the current source
> code of tuxmath? Is it as easy as to remove implementations of the
> shared functions and relink with the common lib? Do function
> signatures change between the two?

No, signatures won't change a bit. The only thing that has to change
is the function call--a function like LoadImage has a common lib
counterpart T4K_LoadImage with the same signature (and usually the
same code, too). What I've been doing so far is using the preprocessor
to redirect the calls instead of manually adding T4K all over the
place. Here's an example from SDL_extras.h in TuxMath's
commonification branch

#ifndef HAVE_LIBT4K_COMMON
void            DrawButton(SDL_Rect* target_rect, int radius, Uint8 r,
Uint8 g, Uint8 b, Uint8 a);
#else
# define DrawButton T4K_DrawButton
#endif

This seems to be the least invasive way to do things, but I'd be glad
to hear any ideas you have :)

Best,
Brendan

Re: [Tuxmath-devel] libt4k_common update

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

Hi Brendan,

Just a quick question: when we eventually move to use libt4k_common
with tuxmath, what changes do we need to make to the current source
code of tuxmath? Is it as easy as to remove implementations of the
shared functions and relink with the common lib? Do function
signatures change between the two?

Cheers
Wenyuan

On Wed, Jun 23, 2010 at 2:23 AM, Brendan Luchen <che...@gm...> wrote:
> Hi all,
>
> Just a quick update--preliminary work on the commonification branch on
> both TuxMath and TuxType are winding down (finally!) with just a few
> minor kinks to work out. The biggest is probably moving to gettext
> 0.18 (make install is still running!) and ensuring that nothing is
> broken. I hope to have more exciting news in a day or two ;)
>
> One question I'd like to bring up in the meantime is how to handle the
> (rather unlikely?) situation where a user wants to build with a
> "canned" version of t4k_common but doesn't have RSVG/SDLPango
> available. This will (and should) presently fail with unresolved
> linkage. libt4k_common can support usage of SDL_ttf or PNG, but I'm
> not sure how easy/possible it is to compile the shared library with
> those flexible dependencies. In essence, we'd be shifting the
> conditional compilation of the backend in functions like LoadImage
> (which prefers, but doesn't need, RSVG) from t4k_common compile time
> to tuxtype compile-time. Worth it? Probably not, but part of me thinks
> it would be fun to try.
>
> Best,
> Brendan
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>

Re: [Tuxmath-devel] libt4k_common update

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

Hi Brendan,

> One question I'd like to bring up in the meantime is how to handle the
> (rather unlikely?) situation where a user wants to build with a
> "canned" version of t4k_common but doesn't have RSVG/SDLPango
> available. This will (and should) presently fail with unresolved
> linkage. libt4k_common can support usage of SDL_ttf or PNG, but I'm
> not sure how easy/possible it is to compile the shared library with
> those flexible dependencies. In essence, we'd be shifting the
> conditional compilation of the backend in functions like LoadImage
> (which prefers, but doesn't need, RSVG) from t4k_common compile time
> to tuxtype compile-time. Worth it? Probably not, but part of me thinks
> it would be fun to try.

So, if I understand correctly, the question is whether it is possible
to compile t4k_common without knowing whether e.g. SDL_Pango is
available at the time of subsequent linkage with tuxtype?  This would
I guess be a sort of conditional linkage, in which the link failures
would result in an attempt to link with the fallback library, rather
than just failing.  I have no idea if this is possible - if it is, I
don't know how to do it.

David

Re: [Tuxmath-devel] libt4k_common update

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

Hi again,

> So, if I understand correctly, the question is whether it is possible
> to compile t4k_common without knowing whether e.g. SDL_Pango is
> available at the time of subsequent linkage with tuxtype?

After a bit of reading, I believe it may be possible to do this by
making t4k_common a regular shared library, and having t4k_common use
dlopen() to call the needed function from SDL_Pango or SDL_ttf at run
time:

http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/dl-libraries.html

But let's defer this until we get our mainstream use cases fully supported.

Best,

David

[Tuxmath-devel] libt4k_common update

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

Hi all,

Just a quick update--preliminary work on the commonification branch on
both TuxMath and TuxType are winding down (finally!) with just a few
minor kinks to work out. The biggest is probably moving to gettext
0.18 (make install is still running!) and ensuring that nothing is
broken. I hope to have more exciting news in a day or two ;)

One question I'd like to bring up in the meantime is how to handle the
(rather unlikely?) situation where a user wants to build with a
"canned" version of t4k_common but doesn't have RSVG/SDLPango
available. This will (and should) presently fail with unresolved
linkage. libt4k_common can support usage of SDL_ttf or PNG, but I'm
not sure how easy/possible it is to compile the shared library with
those flexible dependencies. In essence, we'd be shifting the
conditional compilation of the backend in functions like LoadImage
(which prefers, but doesn't need, RSVG) from t4k_common compile time
to tuxtype compile-time. Worth it? Probably not, but part of me thinks
it would be fun to try.

Best,
Brendan

Re: [Tuxmath-devel] Fwd: gettext 0.18 creating po/Makefile.in.in with wrong GETTEXT_MACRO_VERSION

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

Hi,

> I'd agree. If we're going to make the switch in any case, it may as
> well be during SOC.

OK - I made the executive decision and changed configure.ac in both
tuxtype and tuxmath (all branches) to require 0.18, and ran
"gettextize" on the programs to upgrade all the associated m4 macros
and other files.

So now we need gettext 0.18 to build from git.  Hope this isn't too
much of a pain for anyone involved.

David