Menu
▾
▴
tuxmath-devel — TuxMath developer's mailing list.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(60) |
Sep
(94) |
Oct
(39) |
Nov
(8) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
(9) |
Feb
(1) |
Mar
(14) |
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
(5) |
| 2003 |
Jan
(3) |
Feb
(4) |
Mar
|
Apr
|
May
(3) |
Jun
(1) |
Jul
(2) |
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
(2) |
Feb
(2) |
Mar
(1) |
Apr
(5) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(1) |
Oct
|
Nov
|
Dec
|
| 2005 |
Jan
(1) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(1) |
Mar
(2) |
Apr
(2) |
May
(1) |
Jun
(8) |
Jul
(8) |
Aug
(34) |
Sep
(37) |
Oct
(30) |
Nov
(16) |
Dec
(18) |
| 2007 |
Jan
(7) |
Feb
(31) |
Mar
(52) |
Apr
(49) |
May
(50) |
Jun
(10) |
Jul
(14) |
Aug
(62) |
Sep
(38) |
Oct
(33) |
Nov
(33) |
Dec
(48) |
| 2008 |
Jan
(27) |
Feb
(56) |
Mar
(112) |
Apr
(102) |
May
(108) |
Jun
(75) |
Jul
(44) |
Aug
(103) |
Sep
(24) |
Oct
(32) |
Nov
(7) |
Dec
(66) |
| 2009 |
Jan
(66) |
Feb
(80) |
Mar
(92) |
Apr
(35) |
May
(100) |
Jun
(73) |
Jul
(80) |
Aug
(6) |
Sep
(33) |
Oct
(27) |
Nov
(1) |
Dec
(40) |
| 2010 |
Jan
(10) |
Feb
(8) |
Mar
(130) |
Apr
(50) |
May
(45) |
Jun
(55) |
Jul
(51) |
Aug
(48) |
Sep
(35) |
Oct
(30) |
Nov
(63) |
Dec
(39) |
| 2011 |
Jan
(39) |
Feb
(55) |
Mar
(49) |
Apr
(45) |
May
(24) |
Jun
(20) |
Jul
(6) |
Aug
(5) |
Sep
(11) |
Oct
(22) |
Nov
(18) |
Dec
(19) |
| 2012 |
Jan
(1) |
Feb
(21) |
Mar
(56) |
Apr
(38) |
May
(4) |
Jun
(3) |
Jul
(2) |
Aug
(4) |
Sep
(3) |
Oct
|
Nov
(2) |
Dec
|
| 2013 |
Jan
(17) |
Feb
(13) |
Mar
(21) |
Apr
(24) |
May
(7) |
Jun
(6) |
Jul
(2) |
Aug
(1) |
Sep
(1) |
Oct
(6) |
Nov
|
Dec
(3) |
| 2014 |
Jan
(1) |
Feb
(11) |
Mar
(1) |
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(1) |
Dec
(1) |
| 2015 |
Jan
(2) |
Feb
(3) |
Mar
(8) |
Apr
(1) |
May
(4) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2016 |
Jan
(1) |
Feb
(2) |
Mar
(4) |
Apr
(59) |
May
(7) |
Jun
(4) |
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
(3) |
Dec
(1) |
| 2017 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
|
May
|
Jun
(5) |
Jul
|
Aug
|
Sep
(2) |
Oct
(2) |
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(3) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(5) |
|
From: Jesus M. <fo...@gm...> - 2010-05-28 07:07:50
|
Hi Vikas! 2010/5/28 Vikas Singh <vik...@gm...>: > Hello Jesus, > I think the teacher can be made to control the number of asteroids and the > numbers/fractions being generated on the asteroid, both currently generated > randomly as a function of wave number. > There is no way to read numbers/fractions as such from a file. Exactly, the current version of Factoroids can't read any configuration from config file, it will be nice improve it, but certainly it need some major change. I must admit, I never wrote the game with customization in mind. > > In Factotoids, I want to know what else do you think can be customized by > the teacher and what all do you think can be included in the report eg. wave > number? I think factoroids can be a very exiting game, with bonus and other interesting stuff, but to be realist, for this summer it cant be done, and of curse, you need modify many other aspects of the game, so I think, we can customize: * For each wave there is a increment in the max number, so the numbers for each factorois is being generated using some thing like rand()%max_number. If the teacher can configure the increment of the max_number it will be really interesting... * The same thing with the asteroids generated each wave. Factorids have a hard coded increment, I cant exactly remember, but it will be cool change it. * As you can se, to be easy to play, the tuxship have a very stable way to move around in the space, but it isn't exactly fun. ¿Way not? We can configure this also. * The speed for each asteroid is also hardcoded. If you want, you can configure it, but you need keep in mind if the speed is very fast in a big screen resolution, it is imposible to play in a low one or a windowed mode. I hope this will help, of course I think Tim and the other have much more interesting ideas. Cheers! > -- > Regards , > Vikas Singh > Undergraduate Student, > Computer Science & Engineering, > National Institute Of Technology, > Durgapur-713209 > India > > -- Jesus Mager [www.h1n1-al.blogspot.com] |
|
From: Vikas S. <vik...@gm...> - 2010-05-28 06:20:00
|
Hello Jesus, I think the teacher can be made to control the number of asteroids and the numbers/fractions being generated on the asteroid, both currently generated randomly as a function of wave number. There is no way to read numbers/fractions as such from a file. In Factotoids, I want to know what else do you think can be customized by the teacher and what all do you think can be included in the report eg. wave number? -- Regards , Vikas Singh Undergraduate Student, Computer Science & Engineering, National Institute Of Technology, Durgapur-713209 India |
|
From: Wenyuan G. <guo...@gm...> - 2010-05-28 01:59:58
|
Hi Brendan, I also considered the alternative of enforcing a uniform font size across all menus, but it doesn't quite work with the current program flow: the program must load and display the main menu first before possibly bring up the login menu; it loads lessons menu strictly after the login menu because the former might depend on the latter. Thus at the time when the main menu is loaded, the program has no idea about the longest string it will see in the future (well, it might be possible to do that, but will involve ugly hacks). I think having a separate font size for each level of menu also eases possible future extension, because we are free to add a new level of menu any where in the program without worrying about breaking others. I'm currently trying to tame this beast known as Git. Will update the repository as soon as I'm sure what I'm doing :=) Oh, and you are welcome to steal it :D! Let me know if you find any problem with it. Wenyuan On Fri, May 28, 2010 at 1:52 AM, Brendan Luchen <bm...@ri...> wrote: > Wenyuan, > > >> I propose to solve the problem by associating one font size for each > level > >> of menu. This way the algorithm computing font size for a particular > menu > >> will consistently return the same result even after more menus are > loaded > >> in later phases, a more reasonable behavior I think. I have done the > >> modification and the patch file is attached (it only touches menu.c). > >> > >> What do you think about this solution? > > Looks good! There's a tradeoff to the alternative using the same font > for all menus. On the one hand, you have consistency among all the > menus, which is nice. On the other hand, the font would have to be the > smallest out of all of them, making the main menu look rather small > and cramped. I think your solution is better, unless we can somehow > magically ensure that all menu strings are about the same length, > which is doubtful. > > I'm going to steal your patch and apply it to libt4kcommon :) > > -Brendan > > > ------------------------------------------------------------------------------ > > _______________________________________________ > Tuxmath-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxmath-devel > |
|
From: Brendan L. <bm...@ri...> - 2010-05-27 17:52:48
|
Wenyuan, >> I propose to solve the problem by associating one font size for each level >> of menu. This way the algorithm computing font size for a particular menu >> will consistently return the same result even after more menus are loaded >> in later phases, a more reasonable behavior I think. I have done the >> modification and the patch file is attached (it only touches menu.c). >> >> What do you think about this solution? Looks good! There's a tradeoff to the alternative using the same font for all menus. On the one hand, you have consistency among all the menus, which is nice. On the other hand, the font would have to be the smallest out of all of them, making the main menu look rather small and cramped. I think your solution is better, unless we can somehow magically ensure that all menu strings are about the same length, which is doubtful. I'm going to steal your patch and apply it to libt4kcommon :) -Brendan |
|
From: Brendan L. <che...@gm...> - 2010-05-27 17:32:24
|
Jesus, What I meant was that, usually you give the linker some object files, like "factoroids.o", but I don't see any in the command you posted--just a whole bunch of libraries. Could that be why no main function is found? Best, Brendan On Thu, May 27, 2010 at 1:31 AM, Jesus Mager <fo...@gm...> wrote: > Hi Brendan > > It is a asteroid game (freeasteroids) using my code in tuxmath (and > the whole TuxMath) that id did for school project. On the way I > deleted all files that i didnt need, as in TuxHistory. The every > extraneous thing is: TuxHistory branch are cross compiling well. > (Freeasteroids/TuxHistory difference is mainly the inclusion of > factoroids.c/h) > > If you want (and of course have some time and interest) you can take a look on: > http://sourceforge.net/projects/freeasteroids/develop > or via svn: > svn co https://freeasteroids.svn.sourceforge.net/svnroot/freeasteroids > freeasteroids > > And of course (very initial) TuxHistory sources! > http://git.debian.org/?p=tux4kids/tuxhistory.git > git clone git+ssh://YOU...@gi.../git/tux4kids/tuxhistory.git > > Chears! > > 2010/5/26 Brendan Luchen <che...@gm...>: >> Hey Jesus, >> >> It looks like the error is with SDLmain, not SDL itself.... >> I see -lSDLmain is in there several times, not sure what that means.... >> I don't see any object files, what sources are being compiled? >> >> -Brendan >> >> On Thu, May 27, 2010 at 12:19 AM, Jesus Mager <fo...@gm...> wrote: >>> Hi all, >>> >>> I am setting up the cross compiling environment with >>> mingw32-cross-env, I used the tuxmath INSTALL instructions, but it >>> seems I did someting wrong, or may me a am missing something... >>> >>> My mingw instalation is in /opt/mingw-cross-env from mercurial >>> repository, like the default path in buildw32/cross-configuration, >>> with the following command: make sdl sdl_mixer sdl_image sdl_net >>> sdl_ttf sdl_pango librsvg. and the respective ./tmwin.sh on a clean >>> copy. >>> >>> But I get a linking error to the libsdl. But in configure it seems all >>> OK, any idea? >>> >>> ./cross-configure.sh --host=i686-pc-mingw32 >>> checking build system type... x86_64-pc-linux-gnu >>> checking host system type... i686-pc-mingw32 >>> checking target system type... i686-pc-mingw32 >>> .... >>> checking for SDL... yes >>> checking for SDL_IMAGE... yes >>> checking for SDL_MIXER... yes >>> checking for TTF_Init in -lSDL_ttf... yes >>> checking for RSVG... yes >>> checking for CAIRO... yes >>> >>> make >>> .... >>> >>> i686-pc-mingw32-gcc -Wall -g -DDATA_PREFIX=\"data\" -DDEBUG -DSOUND -g >>> -O2 -D_GNU_SOURCE=1 -Dmain=SDL_main >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL >>> -D_GNU_SOURCE=1 -Dmain=SDL_main >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 >>> -D_GNU_SOURCE=1 -Dmain=SDL_main >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include -mms-bitfields >>> -DLIBXML_STATIC >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/librsvg-2 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/glib-2.0 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/lib/glib-2.0/include >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/gtk-2.0 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/cairo >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libgsf-1 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pango-1.0 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libcroco-0.6 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pixman-1 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/freetype2 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libxml2 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/cairo >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pixman-1 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/freetype2 >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include >>> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 >>> -D__GW32__ -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -o >>> FreeAsteroids.exe >>> /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libintl.a >>> /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libiconv.a >>> ../linebreak/liblinebreak.a -lm -lSDL_ttf -lfreetype -mwindows >>> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lmingw32 -lSDLmain >>> -lSDL -liconv -lm -luser32 -lgdi32 -lwinmm -ldxguid -mwindows >>> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lSDL_image -ltiff >>> -ljpeg -lmingw32 -lSDLmain -lSDL -liconv -lm -luser32 -lgdi32 -lwinmm >>> -ldxguid -lpng14 -lz -mwindows >>> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lSDL_mixer -lmikmod >>> -lpthread -lsmpeg -lstdc++ -lmingw32 -lSDLmain -lSDL -liconv -luser32 >>> -lgdi32 -lwinmm -ldxguid -lvorbisfile -lvorbis -lm -logg >>> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lrsvg-2 >>> -lgdk_pixbuf-2.0 -ltiff -lpng -ljasper -ljpeg -lgsf-1 -lbz2 >>> -lpangocairo-1.0 -lcroco-0.6 -lgio-2.0 -lcairo -lmsimg32 >>> -lpangoft2-1.0 -lpangowin32-1.0 -lgdi32 -lpixman-1 -lpng14 >>> -lfontconfig -lexpat -lfreetype -lpango-1.0 -lm -lgobject-2.0 >>> -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lole32 -lshlwapi -lpcre -lintl >>> -lxml2 -lz -liconv -lws2_32 >>> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lcairo -lmsimg32 >>> -lgdi32 -lm -lpixman-1 -lfontconfig -lexpat -lfreetype -liconv -lpng14 >>> -lz -luuid -lole32 -lwsock32 -mwindows >>> /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libSDLmain.a(SDL_win32_main.o): >>> In function `console_main': >>> /opt/mingw-cross-env/tmp-sdl/SDL-1.2.14/./src/main/win32/SDL_win32_main.c:315: >>> undefined reference to `_SDL_main' >>> collect2: ld returned 1 exit status >>> >>> >>> -- >>> Jesus Mager >>> [www.h1n1-al.blogspot.com] >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Tuxmath-devel mailing list >>> Tux...@li... >>> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel >>> >> > > > > -- > Jesus Mager > [www.h1n1-al.blogspot.com] > |
|
From: David B. <dav...@gm...> - 2010-05-27 12:49:45
|
Hi Jesus, Sorry I don't have time to look at this much right now. As a control, could you try to cross-build tuxtype with mingw-cross-env? I'm pretty sure it should work without problems using the scripts I put in /buildw32. Tuxmath's cross-build is still having problems with detection of sdl_net, but it looks like your issue was something different. I know this "SDL_main" thing is a recurrent issue over the years if you look at the SDL lists for building SDL apps for windows. hth, David |
|
From: Tim H. <ho...@wu...> - 2010-05-27 12:45:16
|
Hi Wenyuan, On Thursday, May 27, 2010 03:05:41 am Wenyuan Guo wrote: > I have managed to find the cause for this strange behavior: [snip] Congrats! Your analysis looks very good. > I propose to solve the problem by associating one font size for each level > of menu. This way the algorithm computing font size for a particular menu > will consistently return the same result even after more menus are loaded > in later phases, a more reasonable behavior I think. I have done the > modification and the patch file is attached (it only touches menu.c). > > What do you think about this solution? I think it's a very nice solution. Of course, an alternative would be to load all menus in advance and calculate a single font size throughout. I do not have a strong preference for one vs. the other; is there anyone who feels they have something informed to say on the topic? On balance I have a slight preference for your solution, largely because of compatibility with the current scheme. Best, --Tim |
|
From: David B. <dav...@gm...> - 2010-05-27 12:43:11
|
Hi Vikas, On Thu, May 27, 2010 at 7:30 AM, Vikas Singh <vik...@gm...> wrote: > Hello, > I have read only tuxmath code and not very familiar with tuxtype code. > I want to know if file operations code for tuxmath and tuxtype same/related > or not ? > If yes, is that same/related code included in libt4k-common library? At one point tuxmath didn't read or write anything to disk at all, apart from loading program data at start-up. We subsequently pulled in some of the code from tuxtype (which was more developed at the time) and worked on it and enhanced it a lot. Now, tuxmath's code is in a lot better shape. The plan with libt4k-common is to further clean it up, and then "port" both tuxmath and tuxtype to use the new library rather than the old functions. libt4k-common is much closer to tuxmath than to tuxtype. > If yes again, then since my code also involves file operations code, so > will that lead to collision or any kind of issue because I will be coding in > tuxmath/tuxtype? Yes, there certainly is some potential for conflicts. My thought would be for you to work on tuxmath in its current architecture (i.e. without libt4k-common), and have Brendan and me try to keep those changes synced with the work on t4k-common. David |
|
From: Vikas S. <vik...@gm...> - 2010-05-27 12:30:59
|
Hello, I have read only tuxmath code and not very familiar with tuxtype code. I want to know if file operations code for tuxmath and tuxtype same/related or not ? If yes, is that same/related code included in libt4k-common library? If yes again, then since my code also involves file operations code, so will that lead to collision or any kind of issue because I will be coding in tuxmath/tuxtype? -- Regards , Vikas Singh Undergraduate Student, Computer Science & Engineering, National Institute Of Technology, Durgapur-713209 India |
|
From: Wenyuan G. <guo...@gm...> - 2010-05-27 08:05:49
|
Hi, I have managed to find the cause for this strange behavior: the program calculates desired sizes for sprites based on the selected font size, which in turn is decided based upon the longest string across all menus loaded. Indeed there is only one global font size used for all levels of menus, a variable named "curr_font_size", which is calculated in function "set_font_size". "set_font_size" will scan all menus loaded *up to the point when it is called* and find the longest string. The problem arises because all menus are not loaded in one go: main menu first, followed by possibly login menu, and then lessons menu. At program startup, it loads main menu, and calls "set_font_size" at that point, which will give it a large font because the main menu doesn't have long strings. This in turns results in larger sprites for them. But when lessons menu is loaded and "set_font_size" invoked a second time, the long strings will shrink the global font size, giving the newly loaded menu items smaller sprite sizes (quite noticeable compared with main menu items). In addition, every time we switch between fullscreen and windowed, "set_font_size" will be re-invoked, this time taking all menus into account and recalculate font and sprite sizes. That's why if we start in fullscreen and press F10 twice to go back to fullscreen, the main menu icons will shrink noticeable (in my cases, it displays 6 icons in the first page, instead 5 which was the case when it started up). This causes some inconsistency in sprite sizes, which has some impact on my project. I propose to solve the problem by associating one font size for each level of menu. This way the algorithm computing font size for a particular menu will consistently return the same result even after more menus are loaded in later phases, a more reasonable behavior I think. I have done the modification and the patch file is attached (it only touches menu.c). What do you think about this solution? Cheers Wenyuan On Sat, May 22, 2010 at 1:04 AM, Brendan Luchen <che...@gm...>wrote: > Good catch, Wenyuan! That's quite funky behavior...I can't think of > any reason for it off the top of my head. I haven't touched that code > in ages either, I'm afraid. > > Best, > Brendan > > On Thu, May 20, 2010 at 1:20 PM, Tim Holy <ho...@wu...> wrote: > > Hi Wenyuan, > > > > On Thursday, May 20, 2010 10:06:56 am you wrote: > >> Hi Dr. Holy, > >> > >> Can you add my Alioth account, > >> > >> guowenyuan-guest > >> > >> to the developer's list, so that I can push my work to the repository (a > >> dedicated branch for my work?) for you to check out? > > > > As far as I can tell, you have not requested to be added to the project. > I > > can't see any way to add you until you do that. I will gladly add you > when I > > can! > > > >> I have started working on the project and have been experimenting with > the > >> code during the last few days. > > > > Great! > > > >> But I have found a quirk in tuxmath: the > >> program will attempt to load the same menu sprites at different > >> resolutions, depending on whether I start the program in fullscreen, or > >> switch to fullscreen in-program (e.g. start in windowed, and press F10); > >> this quirk applies to windowed mode too. > >> > >> To be more specific, by monitoring the parameters passed to function > >> "load_sprite" in "loaders.c", I found that (my fullscreen resolution is > >> 1366*768), > >> 1. start tuxmath in fullscreen, menu sprites are loaded at 77*77 > >> 2. start tuxmath in windowed, menu sprites are loaded at 39*39 > >> 3. switch to fullscreen midway, sprites reloaded at 66*66 > >> 4. switch to windowed midway, sprites reloaded at 32*32 > >> > >> This seems to be a bit strange as the algorithm to calculate these ought > to > >> be the same at the same screen resolution. Are you or any other > developers > >> ware of this issue? Thanks! > > > > I am not, but I haven't looked at this part of the code in ages (not > since > > before last years' GSoC, when it changed). Boleslaw or Brendan might know > > more. > > > > I'm CCing this to tuxmath-devel, so that others can share in our > > correspondence. > > > > Best, > > --Tim > > > > > ------------------------------------------------------------------------------ > > > > _______________________________________________ > > Tuxmath-devel mailing list > > Tux...@li... > > https://lists.sourceforge.net/lists/listinfo/tuxmath-devel > > > |
|
From: Jesus M. <fo...@gm...> - 2010-05-27 05:31:51
|
Hi Brendan It is a asteroid game (freeasteroids) using my code in tuxmath (and the whole TuxMath) that id did for school project. On the way I deleted all files that i didnt need, as in TuxHistory. The every extraneous thing is: TuxHistory branch are cross compiling well. (Freeasteroids/TuxHistory difference is mainly the inclusion of factoroids.c/h) If you want (and of course have some time and interest) you can take a look on: http://sourceforge.net/projects/freeasteroids/develop or via svn: svn co https://freeasteroids.svn.sourceforge.net/svnroot/freeasteroids freeasteroids And of course (very initial) TuxHistory sources! http://git.debian.org/?p=tux4kids/tuxhistory.git git clone git+ssh://YOU...@gi.../git/tux4kids/tuxhistory.git Chears! 2010/5/26 Brendan Luchen <che...@gm...>: > Hey Jesus, > > It looks like the error is with SDLmain, not SDL itself.... > I see -lSDLmain is in there several times, not sure what that means.... > I don't see any object files, what sources are being compiled? > > -Brendan > > On Thu, May 27, 2010 at 12:19 AM, Jesus Mager <fo...@gm...> wrote: >> Hi all, >> >> I am setting up the cross compiling environment with >> mingw32-cross-env, I used the tuxmath INSTALL instructions, but it >> seems I did someting wrong, or may me a am missing something... >> >> My mingw instalation is in /opt/mingw-cross-env from mercurial >> repository, like the default path in buildw32/cross-configuration, >> with the following command: make sdl sdl_mixer sdl_image sdl_net >> sdl_ttf sdl_pango librsvg. and the respective ./tmwin.sh on a clean >> copy. >> >> But I get a linking error to the libsdl. But in configure it seems all >> OK, any idea? >> >> ./cross-configure.sh --host=i686-pc-mingw32 >> checking build system type... x86_64-pc-linux-gnu >> checking host system type... i686-pc-mingw32 >> checking target system type... i686-pc-mingw32 >> .... >> checking for SDL... yes >> checking for SDL_IMAGE... yes >> checking for SDL_MIXER... yes >> checking for TTF_Init in -lSDL_ttf... yes >> checking for RSVG... yes >> checking for CAIRO... yes >> >> make >> .... >> >> i686-pc-mingw32-gcc -Wall -g -DDATA_PREFIX=\"data\" -DDEBUG -DSOUND -g >> -O2 -D_GNU_SOURCE=1 -Dmain=SDL_main >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL >> -D_GNU_SOURCE=1 -Dmain=SDL_main >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 >> -D_GNU_SOURCE=1 -Dmain=SDL_main >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include -mms-bitfields >> -DLIBXML_STATIC >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/librsvg-2 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/glib-2.0 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/lib/glib-2.0/include >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/gtk-2.0 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/cairo >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libgsf-1 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pango-1.0 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libcroco-0.6 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pixman-1 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/freetype2 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libxml2 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/cairo >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pixman-1 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/freetype2 >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include >> -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 >> -D__GW32__ -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -o >> FreeAsteroids.exe >> /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libintl.a >> /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libiconv.a >> ../linebreak/liblinebreak.a -lm -lSDL_ttf -lfreetype -mwindows >> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lmingw32 -lSDLmain >> -lSDL -liconv -lm -luser32 -lgdi32 -lwinmm -ldxguid -mwindows >> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lSDL_image -ltiff >> -ljpeg -lmingw32 -lSDLmain -lSDL -liconv -lm -luser32 -lgdi32 -lwinmm >> -ldxguid -lpng14 -lz -mwindows >> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lSDL_mixer -lmikmod >> -lpthread -lsmpeg -lstdc++ -lmingw32 -lSDLmain -lSDL -liconv -luser32 >> -lgdi32 -lwinmm -ldxguid -lvorbisfile -lvorbis -lm -logg >> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lrsvg-2 >> -lgdk_pixbuf-2.0 -ltiff -lpng -ljasper -ljpeg -lgsf-1 -lbz2 >> -lpangocairo-1.0 -lcroco-0.6 -lgio-2.0 -lcairo -lmsimg32 >> -lpangoft2-1.0 -lpangowin32-1.0 -lgdi32 -lpixman-1 -lpng14 >> -lfontconfig -lexpat -lfreetype -lpango-1.0 -lm -lgobject-2.0 >> -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lole32 -lshlwapi -lpcre -lintl >> -lxml2 -lz -liconv -lws2_32 >> -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lcairo -lmsimg32 >> -lgdi32 -lm -lpixman-1 -lfontconfig -lexpat -lfreetype -liconv -lpng14 >> -lz -luuid -lole32 -lwsock32 -mwindows >> /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libSDLmain.a(SDL_win32_main.o): >> In function `console_main': >> /opt/mingw-cross-env/tmp-sdl/SDL-1.2.14/./src/main/win32/SDL_win32_main.c:315: >> undefined reference to `_SDL_main' >> collect2: ld returned 1 exit status >> >> >> -- >> Jesus Mager >> [www.h1n1-al.blogspot.com] >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Tuxmath-devel mailing list >> Tux...@li... >> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel >> > -- Jesus Mager [www.h1n1-al.blogspot.com] |
|
From: Brendan L. <che...@gm...> - 2010-05-27 04:38:42
|
Hey Jesus, It looks like the error is with SDLmain, not SDL itself.... I see -lSDLmain is in there several times, not sure what that means.... I don't see any object files, what sources are being compiled? -Brendan On Thu, May 27, 2010 at 12:19 AM, Jesus Mager <fo...@gm...> wrote: > Hi all, > > I am setting up the cross compiling environment with > mingw32-cross-env, I used the tuxmath INSTALL instructions, but it > seems I did someting wrong, or may me a am missing something... > > My mingw instalation is in /opt/mingw-cross-env from mercurial > repository, like the default path in buildw32/cross-configuration, > with the following command: make sdl sdl_mixer sdl_image sdl_net > sdl_ttf sdl_pango librsvg. and the respective ./tmwin.sh on a clean > copy. > > But I get a linking error to the libsdl. But in configure it seems all > OK, any idea? > > ./cross-configure.sh --host=i686-pc-mingw32 > checking build system type... x86_64-pc-linux-gnu > checking host system type... i686-pc-mingw32 > checking target system type... i686-pc-mingw32 > .... > checking for SDL... yes > checking for SDL_IMAGE... yes > checking for SDL_MIXER... yes > checking for TTF_Init in -lSDL_ttf... yes > checking for RSVG... yes > checking for CAIRO... yes > > make > .... > > i686-pc-mingw32-gcc -Wall -g -DDATA_PREFIX=\"data\" -DDEBUG -DSOUND -g > -O2 -D_GNU_SOURCE=1 -Dmain=SDL_main > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL > -D_GNU_SOURCE=1 -Dmain=SDL_main > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 > -D_GNU_SOURCE=1 -Dmain=SDL_main > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include -mms-bitfields > -DLIBXML_STATIC > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/librsvg-2 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/glib-2.0 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/lib/glib-2.0/include > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/gtk-2.0 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/cairo > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libgsf-1 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pango-1.0 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libcroco-0.6 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pixman-1 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/freetype2 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libxml2 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/cairo > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pixman-1 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/freetype2 > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include > -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 > -D__GW32__ -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -o > FreeAsteroids.exe > /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libintl.a > /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libiconv.a > ../linebreak/liblinebreak.a -lm -lSDL_ttf -lfreetype -mwindows > -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lmingw32 -lSDLmain > -lSDL -liconv -lm -luser32 -lgdi32 -lwinmm -ldxguid -mwindows > -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lSDL_image -ltiff > -ljpeg -lmingw32 -lSDLmain -lSDL -liconv -lm -luser32 -lgdi32 -lwinmm > -ldxguid -lpng14 -lz -mwindows > -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lSDL_mixer -lmikmod > -lpthread -lsmpeg -lstdc++ -lmingw32 -lSDLmain -lSDL -liconv -luser32 > -lgdi32 -lwinmm -ldxguid -lvorbisfile -lvorbis -lm -logg > -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lrsvg-2 > -lgdk_pixbuf-2.0 -ltiff -lpng -ljasper -ljpeg -lgsf-1 -lbz2 > -lpangocairo-1.0 -lcroco-0.6 -lgio-2.0 -lcairo -lmsimg32 > -lpangoft2-1.0 -lpangowin32-1.0 -lgdi32 -lpixman-1 -lpng14 > -lfontconfig -lexpat -lfreetype -lpango-1.0 -lm -lgobject-2.0 > -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lole32 -lshlwapi -lpcre -lintl > -lxml2 -lz -liconv -lws2_32 > -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lcairo -lmsimg32 > -lgdi32 -lm -lpixman-1 -lfontconfig -lexpat -lfreetype -liconv -lpng14 > -lz -luuid -lole32 -lwsock32 -mwindows > /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libSDLmain.a(SDL_win32_main.o): > In function `console_main': > /opt/mingw-cross-env/tmp-sdl/SDL-1.2.14/./src/main/win32/SDL_win32_main.c:315: > undefined reference to `_SDL_main' > collect2: ld returned 1 exit status > > > -- > Jesus Mager > [www.h1n1-al.blogspot.com] > > ------------------------------------------------------------------------------ > > _______________________________________________ > Tuxmath-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxmath-devel > |
|
From: Jesus M. <fo...@gm...> - 2010-05-27 04:19:12
|
Hi all, I am setting up the cross compiling environment with mingw32-cross-env, I used the tuxmath INSTALL instructions, but it seems I did someting wrong, or may me a am missing something... My mingw instalation is in /opt/mingw-cross-env from mercurial repository, like the default path in buildw32/cross-configuration, with the following command: make sdl sdl_mixer sdl_image sdl_net sdl_ttf sdl_pango librsvg. and the respective ./tmwin.sh on a clean copy. But I get a linking error to the libsdl. But in configure it seems all OK, any idea? ./cross-configure.sh --host=i686-pc-mingw32 checking build system type... x86_64-pc-linux-gnu checking host system type... i686-pc-mingw32 checking target system type... i686-pc-mingw32 .... checking for SDL... yes checking for SDL_IMAGE... yes checking for SDL_MIXER... yes checking for TTF_Init in -lSDL_ttf... yes checking for RSVG... yes checking for CAIRO... yes make .... i686-pc-mingw32-gcc -Wall -g -DDATA_PREFIX=\"data\" -DDEBUG -DSOUND -g -O2 -D_GNU_SOURCE=1 -Dmain=SDL_main -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL -D_GNU_SOURCE=1 -Dmain=SDL_main -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 -D_GNU_SOURCE=1 -Dmain=SDL_main -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/SDL -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include -mms-bitfields -DLIBXML_STATIC -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/librsvg-2 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/glib-2.0 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/lib/glib-2.0/include -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/gtk-2.0 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/cairo -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libgsf-1 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pango-1.0 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libcroco-0.6 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pixman-1 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/freetype2 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libxml2 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/cairo -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/pixman-1 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/freetype2 -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include -I/opt/mingw-cross-env/usr/i686-pc-mingw32/include/libpng14 -D__GW32__ -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -o FreeAsteroids.exe /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libintl.a /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libiconv.a ../linebreak/liblinebreak.a -lm -lSDL_ttf -lfreetype -mwindows -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lmingw32 -lSDLmain -lSDL -liconv -lm -luser32 -lgdi32 -lwinmm -ldxguid -mwindows -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lSDL_image -ltiff -ljpeg -lmingw32 -lSDLmain -lSDL -liconv -lm -luser32 -lgdi32 -lwinmm -ldxguid -lpng14 -lz -mwindows -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lSDL_mixer -lmikmod -lpthread -lsmpeg -lstdc++ -lmingw32 -lSDLmain -lSDL -liconv -luser32 -lgdi32 -lwinmm -ldxguid -lvorbisfile -lvorbis -lm -logg -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lrsvg-2 -lgdk_pixbuf-2.0 -ltiff -lpng -ljasper -ljpeg -lgsf-1 -lbz2 -lpangocairo-1.0 -lcroco-0.6 -lgio-2.0 -lcairo -lmsimg32 -lpangoft2-1.0 -lpangowin32-1.0 -lgdi32 -lpixman-1 -lpng14 -lfontconfig -lexpat -lfreetype -lpango-1.0 -lm -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lglib-2.0 -lole32 -lshlwapi -lpcre -lintl -lxml2 -lz -liconv -lws2_32 -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib -lcairo -lmsimg32 -lgdi32 -lm -lpixman-1 -lfontconfig -lexpat -lfreetype -liconv -lpng14 -lz -luuid -lole32 -lwsock32 -mwindows /opt/mingw-cross-env/usr/i686-pc-mingw32/lib/libSDLmain.a(SDL_win32_main.o): In function `console_main': /opt/mingw-cross-env/tmp-sdl/SDL-1.2.14/./src/main/win32/SDL_win32_main.c:315: undefined reference to `_SDL_main' collect2: ld returned 1 exit status -- Jesus Mager [www.h1n1-al.blogspot.com] |
|
From: David B. <dav...@gm...> - 2010-05-26 17:19:02
|
Hi Brendan, > The more I see, the more I am convinced that it would be > a good move to migrate from autotools if at all possible. The > impression I get is that the autotools paradigm has a rich tradition > in hacks and workarounds, Err, could you be a little more specific? > so by going the CMake route, it may even be > cleaner to use some hacks and workarounds to make it > packager-friendly. My knowledge of CMake is admittedly pretty rudimentary, but I can think of many advantages of autotools off the top of my head: 1. Lots of useful (and essential) built-in targets - make install, make uninstall, make dist, make distcheck, make dist-bz2, and so forth. CMake doesn't even provide a built-in method to install or create tarballs (I believe CPack is the packaging tool). 2. No need for any special build tools on the user's machine - just "./configure; make; make install". While it is just as simple to type "cmake; make", it does require the user to have CMake. 3. Very simple for distro packagers - they are very familiar with autotools packages, so the procedure to make, say, an RPM package is very well-described. Similarly, it is simple to write a MacPorts portfile for an autotools-using project. The biggest *valid* drawback of autotools, IMHO, is that being a GNU project, there is little interest in native Windows support. There is also a lot anti-autotools sentiment that in my opinion comes from them having a long learning curve. Autoconf and Automake are not hard to use, but I do think they are hard to learn how to use. > Static library--any use for one? It's nearly simple as ticking a box > to support dynamic vs. static, but it sounds like dynamic is what's > expected. I agree. The one exception is in the mingw-cross-env build, where everything is static, resulting in a single large executable. But for use on linux, I think a dynamic (shared) library is the right way to do this. > > Another thing I find important is preserving the ability to build TM > and TT from only their respective repos--as opposed to needing the > t4kcommon tree as well, if libt4kcommon is added as a dependency. I've > been pondering how best to to that, possibly by keeping a latest and > greatest build of the library in both games' trees. At least with autotools, for those building from source they just have to first go to the t4kcommon tree, do "./configure; make; sudo make install", then cd to the tuxmath or tuxtype tree and do the same. Once these are packaged, the package manager will handle installing the t4kcommon package if the user does "sudo apt-get install tuxmath". So, basically I don't yet see the advantage to be gained from switching to CMake, other than making it much easier to do a native Windows build. Regards, David |
|
From: Brendan L. <che...@gm...> - 2010-05-26 15:54:51
|
Hi David, I know I've been quiet the past few days, so I just wanted to touch base. I've been dividing my time between frantically getting physically set up (I can type email with a full-sized keyboard again!) and looking at build systems--fooling around with the autotools, getting intimately familiar with our setup, and comparing it with the CMake chain. The more I see, the more I am convinced that it would be a good move to migrate from autotools if at all possible. The impression I get is that the autotools paradigm has a rich tradition in hacks and workarounds, so by going the CMake route, it may even be cleaner to use some hacks and workarounds to make it packager-friendly. A couple of questions: What actually constitutes being packager-friendly? Is it a very platform-dependent question? Are there guidelines on what kind of metadata/organization is needed? Or should I be asking someone else ;)? Static library--any use for one? It's nearly simple as ticking a box to support dynamic vs. static, but it sounds like dynamic is what's expected. If a static lib could possibly make itself useful, then it's worth the small amount of extra baggage--but I don't quite see how it might be, except potentially making the lives easier of users who want to build from scratch. Another thing I find important is preserving the ability to build TM and TT from only their respective repos--as opposed to needing the t4kcommon tree as well, if libt4kcommon is added as a dependency. I've been pondering how best to to that, possibly by keeping a latest and greatest build of the library in both games' trees. But it just occurred to me that it might be a better idea to just leave it up to the user to have libt4kcommon installed, presumably through the package manager. I'm not sure whether that would help or harm the possibility of a versioning/compatibility nightmare. What do you think? Phew. That's longer than I expected. Copying the list. Best, Brendan |
|
From: Vikas S. <vik...@gm...> - 2010-05-25 13:05:25
|
Hi David , Thanks for reply ! Hello Jordan , I have read all the stuff on the wiki page you have setup.It was of great help. I have also read all the last year discussions. I will get back to you later if I need any info from teacher's side (would that be a problem? )after I discuss issues with my mentor. -- Regards , Vikas Singh Undergraduate Student, Computer Science & Engineering, National Institute Of Technology, Durgapur-713209 India |
|
From: Jordan E. <jer...@lo...> - 2010-05-24 22:09:12
|
Hey David/et al., The following wiki page is one I set up last year that David was talking about. It has most of the information for the project, which unfortunately didn't grab asphault. Maybe this is what we need! :) http://wiki.logicalnetworking.net/doku.php?id=tuxtyping&s[]=tuxtype Uwe Geercken (uwe) was incredibly helpful and motivated to help do some database work to meet these ends. He would be a key person to talk to regarding these kinds of improvements. He also works at a school. Sincerely, Jordan David Bruce wrote: > Hi Vikas, > > On Mon, May 24, 2010 at 12:28 AM, Vikas Singh <vik...@gm...> wrote: >> Hi David, >> Can I get the emails from teachers or their archive links that they might >> have sent to Tux4kids ? >> They might have asked some questions and requested for some features in the >> past. >> I may get to know their perspective and their expectations related to what >> we are going to develop. > > There was a pretty active thread last fall on the tuxtype dev list > about student tracking, mostly with ideas from folks who had not > previously contributed to tuxtype. There was even a fairly detailed > suggestion/plan to develop a web-based server that would track > students' progress - all conceived independently of last year's > tux4kids-admin. Also, there is a guy named Jordan Erickson (cc'd on > this mail) who sets up linux thin client-based networks for schools. > Jordan is a big fan of Tux4Kids, but our programs need better student > tracking/reporting to meet the needs of the schools he works with. I > suspect he would be very happy to provide some useful suggestions for > things to work on this summer that would have "real-world" relevance. > > Regards, > > David > > Below is a link to the archives for the tuxtype dev list: > > http://lists.alioth.debian.org/pipermail/tux4kids-tuxtype-dev/ -- Jordan Erickson (707) 636-5678 - http://www.logicalnetworking.net * Please consider the environment before printing this e-mail * |
|
From: David B. <dav...@gm...> - 2010-05-24 19:10:19
|
Hi Vikas, On Mon, May 24, 2010 at 12:28 AM, Vikas Singh <vik...@gm...> wrote: > > Hi David, > Can I get the emails from teachers or their archive links that they might > have sent to Tux4kids ? > They might have asked some questions and requested for some features in the > past. > I may get to know their perspective and their expectations related to what > we are going to develop. There was a pretty active thread last fall on the tuxtype dev list about student tracking, mostly with ideas from folks who had not previously contributed to tuxtype. There was even a fairly detailed suggestion/plan to develop a web-based server that would track students' progress - all conceived independently of last year's tux4kids-admin. Also, there is a guy named Jordan Erickson (cc'd on this mail) who sets up linux thin client-based networks for schools. Jordan is a big fan of Tux4Kids, but our programs need better student tracking/reporting to meet the needs of the schools he works with. I suspect he would be very happy to provide some useful suggestions for things to work on this summer that would have "real-world" relevance. Regards, David Below is a link to the archives for the tuxtype dev list: http://lists.alioth.debian.org/pipermail/tux4kids-tuxtype-dev/ |
|
From: Jesus M. <fo...@gm...> - 2010-05-24 06:42:19
|
Hi akash and all! TuxHistory git repo is on. You can access it using git clone git+ssh://YOU...@gi.../git/tux4kids/tuxhistory.git if some one want a read-only local rep git clone git://git.debian.org/git/tux4kids/tuxhistory.git and the web version: http://git.debian.org/?p=tux4kids/tuxhistory.git I'm not sure if the mail hook is working. I made a probe commit, but it appears it is not working. May be, because it is the first mail it need some moderation, but if this is not the case, please tell me! I hope this summer will be really productive for tux4kids, happy coding for all students and mentors. We are starting... -- Jesus Mager [www.h1n1-al.blogspot.com] |
|
From: Brendan L. <che...@gm...> - 2010-05-21 17:04:57
|
Good catch, Wenyuan! That's quite funky behavior...I can't think of any reason for it off the top of my head. I haven't touched that code in ages either, I'm afraid. Best, Brendan On Thu, May 20, 2010 at 1:20 PM, Tim Holy <ho...@wu...> wrote: > Hi Wenyuan, > > On Thursday, May 20, 2010 10:06:56 am you wrote: >> Hi Dr. Holy, >> >> Can you add my Alioth account, >> >> guowenyuan-guest >> >> to the developer's list, so that I can push my work to the repository (a >> dedicated branch for my work?) for you to check out? > > As far as I can tell, you have not requested to be added to the project. I > can't see any way to add you until you do that. I will gladly add you when I > can! > >> I have started working on the project and have been experimenting with the >> code during the last few days. > > Great! > >> But I have found a quirk in tuxmath: the >> program will attempt to load the same menu sprites at different >> resolutions, depending on whether I start the program in fullscreen, or >> switch to fullscreen in-program (e.g. start in windowed, and press F10); >> this quirk applies to windowed mode too. >> >> To be more specific, by monitoring the parameters passed to function >> "load_sprite" in "loaders.c", I found that (my fullscreen resolution is >> 1366*768), >> 1. start tuxmath in fullscreen, menu sprites are loaded at 77*77 >> 2. start tuxmath in windowed, menu sprites are loaded at 39*39 >> 3. switch to fullscreen midway, sprites reloaded at 66*66 >> 4. switch to windowed midway, sprites reloaded at 32*32 >> >> This seems to be a bit strange as the algorithm to calculate these ought to >> be the same at the same screen resolution. Are you or any other developers >> ware of this issue? Thanks! > > I am not, but I haven't looked at this part of the code in ages (not since > before last years' GSoC, when it changed). Boleslaw or Brendan might know > more. > > I'm CCing this to tuxmath-devel, so that others can share in our > correspondence. > > Best, > --Tim > > ------------------------------------------------------------------------------ > > _______________________________________________ > Tuxmath-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxmath-devel > |
|
From: Bill K. <nb...@so...> - 2010-05-20 23:35:33
|
On Thu, May 20, 2010 at 01:38:24PM -0500, David Bruce wrote: > We still use tux...@li... as the tuxmath dev > list. AFAIK, we use the Alioth lists for everything else. Tux Paint's lists are all on SourceForge.net. ... except tuxpaint-news, because at one point I was manually bulk-subscribing people to it, when they filled out the survey form on the website and said "I'm interested in updates". Nowadays, the form acceptor script shoves a subscription request behind the scenes, so people who fill out the survey will get a "Please confirm subscription" message from Mailman automatically. In any case, -news list is run on tuxpaint.org itself (thanks to help from Cernio folks in getting that set up). -bill! |
|
From: Sam H. <cri...@gm...> - 2010-05-20 18:54:04
|
On Thu, May 20, 2010 at 2:38 PM, David Bruce <dav...@gm...> wrote: > We still use tux...@li... as the tuxmath dev > list. AFAIK, we use the Alioth lists for everything else. I'm not > subscribed to any other SF.net T4K lists. I guess it would be fair > for me to take over any residual maintenance of the SF.net stuff. I > try to keep fairly recent builds posted there, although I haven't > really kept the tuxmath and tuxtype pages there very current. Honestly, for the ones not being used, they are just sources of spam at this point (spam-bots try to send spam to closed lists, list admin gets copy of spam, etc.) so I'm not sure there's a real need to have someone else be added to the administrative spam feed :-) As far as the rest goes, looking at the perms for the projects I still have admin on, you (David) have elevated privileges on them including "list/forum moderator", so you should be able to do everything already. I'm actually surprised you don't get the administrative mailings already. |
|
From: David B. <dav...@gm...> - 2010-05-20 18:38:31
|
Hi Sam, > Hah! Correction, I guess you guys *are* still using some of the old > SF.net mailing lists :-) > > Well, in that case, are there any other people getting these > administrative emails from the mailing lists, or is it just me? > Because I've been ignoring them (even had them going to the wrong > email address) since I stepped down as T4K head in 2005 :-) We still use tux...@li... as the tuxmath dev list. AFAIK, we use the Alioth lists for everything else. I'm not subscribed to any other SF.net T4K lists. I guess it would be fair for me to take over any residual maintenance of the SF.net stuff. I try to keep fairly recent builds posted there, although I haven't really kept the tuxmath and tuxtype pages there very current. David Bruce |
|
From: Tim H. <ho...@wu...> - 2010-05-20 17:21:06
|
Hi Wenyuan, On Thursday, May 20, 2010 10:06:56 am you wrote: > Hi Dr. Holy, > > Can you add my Alioth account, > > guowenyuan-guest > > to the developer's list, so that I can push my work to the repository (a > dedicated branch for my work?) for you to check out? As far as I can tell, you have not requested to be added to the project. I can't see any way to add you until you do that. I will gladly add you when I can! > I have started working on the project and have been experimenting with the > code during the last few days. Great! > But I have found a quirk in tuxmath: the > program will attempt to load the same menu sprites at different > resolutions, depending on whether I start the program in fullscreen, or > switch to fullscreen in-program (e.g. start in windowed, and press F10); > this quirk applies to windowed mode too. > > To be more specific, by monitoring the parameters passed to function > "load_sprite" in "loaders.c", I found that (my fullscreen resolution is > 1366*768), > 1. start tuxmath in fullscreen, menu sprites are loaded at 77*77 > 2. start tuxmath in windowed, menu sprites are loaded at 39*39 > 3. switch to fullscreen midway, sprites reloaded at 66*66 > 4. switch to windowed midway, sprites reloaded at 32*32 > > This seems to be a bit strange as the algorithm to calculate these ought to > be the same at the same screen resolution. Are you or any other developers > ware of this issue? Thanks! I am not, but I haven't looked at this part of the code in ages (not since before last years' GSoC, when it changed). Boleslaw or Brendan might know more. I'm CCing this to tuxmath-devel, so that others can share in our correspondence. Best, --Tim |
|
From: Berte, M. <mb...@fo...> - 2010-05-19 14:50:05
|
We have your tux math program loaded on all of our computers at our school. It is a great program. Unfortunately we have discovered that kids like to type in things other than their name when they have made it to the Hall of Fame. Is there a way of getting in an removing names from the Hall of Fame other than beating the score? Please help us with this situation. Thank you for your programs. Hopefully this will make it better. Maybe there should be some kind of code that teachers have before kids can enter their names in the hall of fame or that only teachers can enter them. Marlene Berte Library Media Para-Educator Duncombe Elementary School 574-5634 |
75 messages has been excluded from this view by a project administrator.
