Menu
▾
▴
tuxmath-devel
|
From: Brendan L. <che...@gm...> - 2010-06-22 18:24:01
|
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 |
|
From: David B. <dav...@gm...> - 2010-06-22 21:15:29
|
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 |
|
From: David B. <dav...@gm...> - 2010-06-22 21:00:07
|
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 |
|
From: Wenyuan G. <guo...@gm...> - 2010-06-25 02:27:11
|
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 > |
|
From: Brendan L. <che...@gm...> - 2010-06-25 04:25:14
|
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 |
|
From: David B. <dav...@gm...> - 2010-06-25 11:09:35
|
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 |
|
From: Brendan L. <che...@gm...> - 2010-06-25 18:28:45
|
> 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 |
|
From: Wenyuan G. <guo...@gm...> - 2010-06-26 02:50:28
|
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 > |
|
From: Brendan L. <che...@gm...> - 2010-06-27 15:16:59
|
> 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 |
|
From: David B. <dav...@gm...> - 2010-06-28 02:50:09
|
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 |
|
From: Brendan L. <che...@gm...> - 2010-06-28 16:30:58
|
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 |
|
From: David B. <dav...@gm...> - 2010-06-29 00:44:42
|
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 |
|
From: David B. <dav...@gm...> - 2010-07-02 01:28:28
|
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 |
|
From: Brendan L. <che...@gm...> - 2010-07-02 15:22:59
|
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 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X