tuxmath-devel — TuxMath developer's mailing list.

[Tuxmath-devel] Informação Tux Math

[luana s. <lua...@ho...>]

 
 Boa Tarde,
 
 
   Sou a Luana , curso o 4º ano de Sistemas de Informação, trabalho em um Laboratório
de Informática em uma escola municipal, entrei em contato com voceis porque
estou fazendo minha monografia sobre " A Utilização do Software Educativo 
Tux Math como recurso de ensino aprendizagem em aulas de matemática.",
estive pesquisando sobre esse Software educativo e não achei praticamente nada,
gostaria da ajuda de voceis em me informa sobre a Origem,o Por quê, os Desenvolvedores
desse jogo. Parabéns pela criação é um jogo muito bom para ensinar matemática
   Desde já agradeço a compreensão de todos.
 
            att,
 
 
Luana Souza
Rondonópolis-MT
 
 
 
  		 	   		  

Re: [Tuxmath-devel] tuxmath fails to compile without sdlttf

[Volker G. <vo...@no...>]

Tasos Latsas schrieb:
> Volker Grabsch wrote:
> > Currently, lots of projects are facing the same issues and the same
> > ugly workaround as you do - not because the library authors don't
> > provide *.pc file, but because the distributions don't install those.
> > That's what's making all your life unnecessarily hard. As soon as
> > all major distros fix those issues, many projects will be able to
> > throw out lots of workarounds from their configure.ac files. :-)
> > 
> Yes I understand that, I'll try to file some this weekend and post back.
> Maybe a feature request instead of a bugreport would be more appropriate?

I don't know. It's really hard to say whether a missing installed file
is a bug or a missing feature.

> One last thing, under which packages should I file them? sdl_ttf and
> sdl_mixer, or sdl_ttf only?

I'd report it under each package where this bug occurs on the given
distribution.


Gruß
Volker

-- 
Volker Grabsch
---<<(())>>---

Re: [Tuxmath-devel] tuxmath fails to compile without sdlttf

[Tasos L. <tla...@gm...>]

On 02/10/2011 03:22 PM, Volker Grabsch wrote:
> Tasos Latsas schrieb:
>> I will also look into it, see how I can help, but I don't promise as
>> pkg-config/Autoconf stuff are new to me..
> 
> Feel free to ask if you run into any problems. I'd be happy to have
> a look at your *.ac / *.in files.
> 
>>> However, some distributions like Debian don't install those, maybe
>>> because their build scripts were written in a time where those libraries
>>> didn't provide a *.pc file. I think it would be a good idea to provide
>>> bug reports for those distributions, but I didn't yet find the time
>>> to do that. Any volunteers?
>>
>> From a quick look here [1] only Archlinux and Fedora from the major
>> distributions ship SDL_ttf.pc (i dont know if this list is up-to-date
>> though). I could file those bug reports if the Autoconf solution doesn't
>> work.
> 
> The distro bugreports are not about how to make things _work_; they
> are about how to make things _easier_. So I recommend to file those
> bugreports in any case, if you find some time for that. The bugreports
> are not to solve things _now_, but to make things better in the future.
> 
> Currently, lots of projects are facing the same issues and the same
> ugly workaround as you do - not because the library authors don't
> provide *.pc file, but because the distributions don't install those.
> That's what's making all your life unnecessarily hard. As soon as
> all major distros fix those issues, many projects will be able to
> throw out lots of workarounds from their configure.ac files. :-)
> 
> 
Yes I understand that, I'll try to file some this weekend and post back.
Maybe a feature request instead of a bugreport would be more appropriate?
One last thing, under which packages should I file them? sdl_ttf and
sdl_mixer, or sdl_ttf only?

Thanks

-- 
Tasos Latsas

GPG   : 0x219810C9 / B487 351A 6EEC B7C3 E78E  F4D9 7217 5B4B 2198 10C9
Jabber: tl...@ja...
www   : http://ttys.homelinux.net

Re: [Tuxmath-devel] tuxmath fails to compile without sdlttf

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

Hi Volker, Tasos,

I removed the unneeded T4K_COMMON prefix from the vars as suggested.
For the moment I still have separate DEP_LIBS and DEP_LIBS_PRIVATE,
but I can simplify that later.

The update is in t4k_common's git repo:

git clone git://git.debian.org/git/tux4kids/t4kcommon.git

> Feel free to ask if you run into any problems. I'd be happy to have
> a look at your *.ac / *.in files.

Thanks - I've attached those files.  I can think of a few things I
haven't yet addressed:
1. DEP_LIBS_PRIVATE as of yet is just contains all the secondary
dependencies for all the non- *.pc libs.  It was not created very
carefully, basically grabbed from the args passed to gcc at the end of
the regular linux non-static build process, after which I eliminated
duplicates and the primary dependencies.  So it might possibly have
some things in there that wouldn't be needed if some of the optional
libs are deselected.  I think I should make the lib checks in
configure.ac mimic the pkg-config process more closely, adding to this
var as each library is located.
2. As you suggested, the lib checks use a two stage procedure, first
trying PKG_CHECK_MODULES, then AC_CHECK_LIB if needed.  Once the lib
is detected, by either method, I add the library name to DEP_LIBS (for
the ones I know have *.pc files).  But this might result in an error
if the fall-back to AC_CHECK_LIB was required.  So I think perhaps
DEP_LIBS should be updated in the "action_if_found" part of
PKG_CHECK_MODULES.

I will look at some *.pc.in files from other projects, as you
suggested, for working examples I can follow.

Thanks,

David

Re: [Tuxmath-devel] tuxmath fails to compile without sdlttf

[Volker G. <vo...@no...>]

Tasos Latsas schrieb:
> I will also look into it, see how I can help, but I don't promise as
> pkg-config/Autoconf stuff are new to me..

Feel free to ask if you run into any problems. I'd be happy to have
a look at your *.ac / *.in files.

> > However, some distributions like Debian don't install those, maybe
> > because their build scripts were written in a time where those libraries
> > didn't provide a *.pc file. I think it would be a good idea to provide
> > bug reports for those distributions, but I didn't yet find the time
> > to do that. Any volunteers?
> 
> From a quick look here [1] only Archlinux and Fedora from the major
> distributions ship SDL_ttf.pc (i dont know if this list is up-to-date
> though). I could file those bug reports if the Autoconf solution doesn't
> work.

The distro bugreports are not about how to make things _work_; they
are about how to make things _easier_. So I recommend to file those
bugreports in any case, if you find some time for that. The bugreports
are not to solve things _now_, but to make things better in the future.

Currently, lots of projects are facing the same issues and the same
ugly workaround as you do - not because the library authors don't
provide *.pc file, but because the distributions don't install those.
That's what's making all your life unnecessarily hard. As soon as
all major distros fix those issues, many projects will be able to
throw out lots of workarounds from their configure.ac files. :-)


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---

Re: [Tuxmath-devel] tuxmath fails to compile without sdlttf

[Tasos L. <tla...@gm...>]

On 02/09/2011 10:06 PM, David Bruce wrote:
> Hi Volker,
> 
> That helps a lot - I just want to make sure I understand correctly.
> 
>> This is not a question of pkg-config. It is a question of Autoconf.
>> If you collect some helper variables during the checks in configure.ac,
>> you can simply include those variables in your *.pc.in file. (something
>> like @DEP_PKGS@, @DEP_LIBS@)
> 
> Thanks - so I've created the following:
> T4K_COMMON_DEP_PKGS - for needed libs that have *.pc files
> T4K_COMMON_DEP_LIBS - for needed libs without *.pc files
> T4K_COMMON_DEP_LIBS_PRIVATE - for secondary dependencies incurred by
> libs without *.pc files.
> 
> So the t4k_common.pc.in is now very simple (see below).
> 
> For now, I've just hard-coded the previous values into these variables
> within configure.ac to be sure the substitution is working as
> intended, so the build isn't yet any smarter than before.  So, if I
> make sure these variables correctly track the configure options (e.g.
> SDL_Pango vs. SDL_ttf, SDL_net vs no network support, etc.), this
> should work as intended, if I understand correctly.
> 
> Thanks a ton -
> 
> David
> 
> 
> t4k_common.pc.in: ----------------------------------------------------
> 
> # Process with configure script to generate t4k_common.pc file for pkg-config
> # NOTE: we rely heavily on substituted output variables from Autoconf
> # or Cmake to generate a t4k_common.pc that reflects conditional build
> # with optional libraries.
> 
> prefix=@prefix@
> exec_prefix=@exec_prefix@
> libdir=@libdir@
> includedir=@includedir@
> 
> Name: @PACKAGE_NAME@
> Description: Tux4Kids common routines
> Version: @VERSION@
> 
> # List needed libs that have *.pc files in "Requires:"
> Requires: @T4K_COMMON_DEP_PKGS@
> # List libs "by hand" that don't have .pc files:
> Libs: -l@PACKAGE_TARNAME@ -L${libdir} @T4K_COMMON_DEP_LIBS@
> Cflags: -I${includedir}
> 
> # List secondary dependencies of libs that don't have *.pc files
> # (needed for static linking)
> Libs.private: @T4K_COMMON_DEP_LIBS_PRIVATE@

Wow that was fast..
Will this be commited to the git repo? Where can I pull the changes from?

Thank you everyone! =)

-- 
Tasos Latsas

GPG   : 0x219810C9 / B487 351A 6EEC B7C3 E78E  F4D9 7217 5B4B 2198 10C9
Jabber: tl...@ja...
www   : http://ttys.homelinux.net

Re: [Tuxmath-devel] tuxmath fails to compile without sdlttf

[Volker G. <vo...@no...>]

David Bruce schrieb:
> Hi Volker,
> 
> > This is not a question of pkg-config. It is a question of Autoconf.
> > If you collect some helper variables during the checks in configure.ac,
> > you can simply include those variables in your *.pc.in file. (something
> > like @DEP_PKGS@, @DEP_LIBS@)
> 
> Thanks - so I've created the following:
> T4K_COMMON_DEP_PKGS - for needed libs that have *.pc files
> T4K_COMMON_DEP_LIBS - for needed libs without *.pc files
> T4K_COMMON_DEP_LIBS_PRIVATE - for secondary dependencies incurred by
> libs without *.pc files.
> 
> So the t4k_common.pc.in is now very simple (see below).

Your solution is quite close to what I had in mind. However,
I would change two things:

1) drop the 'T4K_COMMON_' prefix, as the other names are
   already unambiguous within a single project.

2) is the DEP_LIBS (aka T4K_COMMON_DEP_LIBS) variable
   really necessary? As long as you produce a shared
   library, there is no need to explicitly specify the
   dependency libs. I think you can safely put all
   non-*.pc libraries together with its secondary
   dependencies into DEP_LIBS_PRIVATE.

Note that I assume in 2) that your library is created
as a shared library. However, if it is really always
linked statically, in mingw-cross-env as well as all
other toolchains, then your approach is correct.

BTW, in mingw-cross-env (i686-pc-mingw32-pkg-config) the
--static flag is always provided, so Libs.private is
always used.


> For now, I've just hard-coded the previous values into these variables
> within configure.ac to be sure the substitution is working as
> intended, so the build isn't yet any smarter than before.  So, if I
> make sure these variables correctly track the configure options (e.g.
> SDL_Pango vs. SDL_ttf, SDL_net vs no network support, etc.), this
> should work as intended, if I understand correctly.

Yes, that's the idea.

The strategy I described here is used but a lot of other
libraries. You might want to have a look at the *.pc.in
files of other packages like cURL or GTK. Those will give
you some more ideas about how to manage these things.


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---

Re: [Tuxmath-devel] tuxmath fails to compile without sdlttf

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

Hi Volker,

That helps a lot - I just want to make sure I understand correctly.

> This is not a question of pkg-config. It is a question of Autoconf.
> If you collect some helper variables during the checks in configure.ac,
> you can simply include those variables in your *.pc.in file. (something
> like @DEP_PKGS@, @DEP_LIBS@)

Thanks - so I've created the following:
T4K_COMMON_DEP_PKGS - for needed libs that have *.pc files
T4K_COMMON_DEP_LIBS - for needed libs without *.pc files
T4K_COMMON_DEP_LIBS_PRIVATE - for secondary dependencies incurred by
libs without *.pc files.

So the t4k_common.pc.in is now very simple (see below).

For now, I've just hard-coded the previous values into these variables
within configure.ac to be sure the substitution is working as
intended, so the build isn't yet any smarter than before.  So, if I
make sure these variables correctly track the configure options (e.g.
SDL_Pango vs. SDL_ttf, SDL_net vs no network support, etc.), this
should work as intended, if I understand correctly.

Thanks a ton -

David


t4k_common.pc.in: ----------------------------------------------------

# Process with configure script to generate t4k_common.pc file for pkg-config
# NOTE: we rely heavily on substituted output variables from Autoconf
# or Cmake to generate a t4k_common.pc that reflects conditional build
# with optional libraries.

prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
includedir=@includedir@

Name: @PACKAGE_NAME@
Description: Tux4Kids common routines
Version: @VERSION@

# List needed libs that have *.pc files in "Requires:"
Requires: @T4K_COMMON_DEP_PKGS@
# List libs "by hand" that don't have .pc files:
Libs: -l@PACKAGE_TARNAME@ -L${libdir} @T4K_COMMON_DEP_LIBS@
Cflags: -I${includedir}

# List secondary dependencies of libs that don't have *.pc files
# (needed for static linking)
Libs.private: @T4K_COMMON_DEP_LIBS_PRIVATE@

Re: [Tuxmath-devel] tuxmath fails to compile without sdlttf

[Tasos L. <tla...@gm...>]

On 02/09/2011 02:20 AM, Volker Grabsch wrote:
> David Bruce schrieb:
>> I think the problem is in t4k_common's pkg-config file,
>> t4k_common.pc.in (reproduced below).  My knowledge of pkg-config is
>> limited, but looking at the file it's pretty clear that I hard-coded a
>> dependency on SDL_ttf into the "Libs" section.   t4k_common's build
>> process can detect if SDL_Pango is available, but the problem comes in
>> with the static linking needed for the mingw-cross-env build.  For
>> static linking, t4k_common needs to supply all the compiler arguments
>> for all the dependencies, and this only works "automagically" for
>> dependencies that themselves have pkg-config *.pc files. 
> 
> Note that a *.pc file can "Require" another package. The idea is
> that you don't have to specify anything but your own stuff in the
> "Libs" section.
> 
> However, this works only for dependencies that provide a *.pc file.
> All other libs you'll have to specify in your "Libs.private" section.
> (which will only be used for static builds, in contrast to "Libs")
> 
>> I haven't
>> figured out how to write a *.pc file that conditionally passes the
>> arguments for either SDL_Pango (plus its deps) or SDL_ttf (plus deps)
>> to the tuxmath linking step.
> 
> This is not a question of pkg-config. It is a question of Autoconf.
> If you collect some helper variables during the checks in configure.ac,
> you can simply include those variables in your *.pc.in file. (something
> like @DEP_PKGS@, @DEP_LIBS@)
> 
> In general, I recommend to check for each library whether it is
> available via pkg-config. If it isn't, try something like AC_CHECK_LIB
> as a workaround.
> 
>     PKG_CHECK_EXISTS([...],
>         PKG_CHECK_MODULES([...],
>         AC_CHECK_LIB(...)
>     )
> 

I will also look into it, see how I can help, but I don't promise as
pkg-config/Autoconf stuff are new to me..

> One final thought: Nowadays almost all libraries ship with *.pc files.
> However, some distributions like Debian don't install those, maybe
> because their build scripts were written in a time where those libraries
> didn't provide a *.pc file. I think it would be a good idea to provide
> bug reports for those distributions, but I didn't yet find the time
> to do that. Any volunteers?
> 

From a quick look here [1] only Archlinux and Fedora from the major
distributions ship SDL_ttf.pc (i dont know if this list is up-to-date
though). I could file those bug reports if the Autoconf solution doesn't
work.

> 
> Greets,
> Volker
> 

Cheers

[1]
http://pkgs.org/search/?keyword=sdl_ttf&search_on=smart&distro=0&arch=32-bit&exact=0

-- 
Tasos Latsas

GPG   : 0x219810C9 / B487 351A 6EEC B7C3 E78E  F4D9 7217 5B4B 2198 10C9
Jabber: tl...@ja...
www   : http://ttys.homelinux.net

Re: [Tuxmath-devel] tuxmath fails to compile without sdlttf

[Volker G. <vo...@no...>]

David Bruce schrieb:
> I think the problem is in t4k_common's pkg-config file,
> t4k_common.pc.in (reproduced below).  My knowledge of pkg-config is
> limited, but looking at the file it's pretty clear that I hard-coded a
> dependency on SDL_ttf into the "Libs" section.   t4k_common's build
> process can detect if SDL_Pango is available, but the problem comes in
> with the static linking needed for the mingw-cross-env build.  For
> static linking, t4k_common needs to supply all the compiler arguments
> for all the dependencies, and this only works "automagically" for
> dependencies that themselves have pkg-config *.pc files. 

Note that a *.pc file can "Require" another package. The idea is
that you don't have to specify anything but your own stuff in the
"Libs" section.

However, this works only for dependencies that provide a *.pc file.
All other libs you'll have to specify in your "Libs.private" section.
(which will only be used for static builds, in contrast to "Libs")

> I haven't
> figured out how to write a *.pc file that conditionally passes the
> arguments for either SDL_Pango (plus its deps) or SDL_ttf (plus deps)
> to the tuxmath linking step.

This is not a question of pkg-config. It is a question of Autoconf.
If you collect some helper variables during the checks in configure.ac,
you can simply include those variables in your *.pc.in file. (something
like @DEP_PKGS@, @DEP_LIBS@)

In general, I recommend to check for each library whether it is
available via pkg-config. If it isn't, try something like AC_CHECK_LIB
as a workaround.

    PKG_CHECK_EXISTS([...],
        PKG_CHECK_MODULES([...],
        AC_CHECK_LIB(...)
    )

One final thought: Nowadays almost all libraries ship with *.pc files.
However, some distributions like Debian don't install those, maybe
because their build scripts were written in a time where those libraries
didn't provide a *.pc file. I think it would be a good idea to provide
bug reports for those distributions, but I didn't yet find the time
to do that. Any volunteers?


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---

Re: [Tuxmath-devel] query regarding server

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

Hi,

On Tue, Feb 8, 2011 at 7:40 PM, deepak aggarwal
<dee...@gm...> wrote:
> hi David
>  I want to ask how a client find out server without knowing servers ip
> address.
> and whether i should use TCP or UDP connection for sending data to client.

You might look at what we currently do.
1.  Using UDP, you can broadcast a packet to every machine on the LAN.
 That's what the client does now.  The server detects this and sends
back a UDP packet telling the ip and port where the client can connect
over TCP.
2.  Use TCP for the actual game connection.  Our data is not
redundant, and there is no performance consideration here to suggest
using UDP instead.

HTH,

David

[Tuxmath-devel] query regarding server

[deepak a. <dee...@gm...>]

hi David
 I want to ask how a client find out server without knowing servers ip
address.
and whether i should use TCP or UDP connection for sending data to client.

Re: [Tuxmath-devel] tuxmath fails to compile without sdlttf

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

Hi Tasos,

On Tue, Feb 8, 2011 at 7:29 AM, Tasos Latsas <tla...@gm...> wrote:
> Hello,
> I created pkgbuilds for the Archlinux distribution, for tuxmath [1] and
> t4k_common [2].
> t4k_common compiles fine but tuxmath fails with:
> /usr/bin/ld: cannot find -lSDL_ttf
>
> I have sdl_pango installed, I thought that it will use sdl_pango if
> present and if not then fallback to sdl_ttf. (correct me if I am wrong)

Yes, that's how it is supposed to work, and how it does work at run
time, but it looks like we are requiring SDL_ttf in the build even
though it doesn't actually get used.

> If I explicitly install sdl_ttf then tuxmath compiles and works fine but
> i can't see any links to sdl_ttf using ldd.

I think the problem is in t4k_common's pkg-config file,
t4k_common.pc.in (reproduced below).  My knowledge of pkg-config is
limited, but looking at the file it's pretty clear that I hard-coded a
dependency on SDL_ttf into the "Libs" section.   t4k_common's build
process can detect if SDL_Pango is available, but the problem comes in
with the static linking needed for the mingw-cross-env build.  For
static linking, t4k_common needs to supply all the compiler arguments
for all the dependencies, and this only works "automagically" for
dependencies that themselves have pkg-config *.pc files.  I haven't
figured out how to write a *.pc file that conditionally passes the
arguments for either SDL_Pango (plus its deps) or SDL_ttf (plus deps)
to the tuxmath linking step.  Have I confused everyone yet?

If anyone else on this list is proficient with pkg-config, help would
be appreciated.

I'm cc'ing Volker Grabsch (mingw-cross-env maintainer) in case this
issue has come up in static linking for other mingw-cross-env
packages, and because Volker seems to know this stuff really, really
well.

David Bruce



t4kcommon/t4k_common.pc.in:   --------------------------------------------------

prefix=@prefix@
exec_prefix=@exec_prefix@
libdir=@libdir@
includedir=@includedir@

Name: @PACKAGE_NAME@
Description: Tux4Kids common routines
Version: @VERSION@

# AFAICT we can only list libs with .pc files in "Requires:"
Requires: sdl >= 1.2.0 SDL_image SDL_Pango librsvg-2.0 libxml-2.0
# List libs "by hand" that don't have .pc files:
Libs: -l@PACKAGE_TARNAME@ -L${libdir} -lSDL_mixer -lSDL_ttf -lSDL_net
Cflags: -I${includedir}

# Because SDL_mixer and SDL_ttf do not have .pc files on some platforms,
# we list their static dependencies here:

Libs.private: -mwindows -L/opt/mingw-cross-env/usr/i686-pc-mingw32/lib
-lmikmod -lsmpeg -lstdc++ -lmingw32 -lSDLmain -liconv -luser32 -lgdi32
-lwinmm -ldxguid -lSDL -lpthread -lvorbisfile -lvorbis -lm -logg
-lfreetype

[Tuxmath-devel] tuxmath fails to compile without sdlttf

[Tasos L. <tla...@gm...>]

Hello,
I created pkgbuilds for the Archlinux distribution, for tuxmath [1] and
t4k_common [2].
t4k_common compiles fine but tuxmath fails with:
/usr/bin/ld: cannot find -lSDL_ttf

I have sdl_pango installed, I thought that it will use sdl_pango if
present and if not then fallback to sdl_ttf. (correct me if I am wrong)

I have set the following dependencies:
t4k_common : librsvg sdl_image sdl_mixer sdl_net sdl_pango
tuxmath: t4k_common

If I explicitly install sdl_ttf then tuxmath compiles and works fine but
i can't see any links to sdl_ttf using ldd.

tuxmath: 1.9.0
t4k_common: 0.0.3 (I also tried with 0.1.0)

[1] http://aur.archlinux.org/packages.php?ID=22660
[2] http://aur.archlinux.org/packages.php?ID=45252

Thank you

-- 
Tasos Latsas

GPG   : 0x219810C9 / B487 351A 6EEC B7C3 E78E  F4D9 7217 5B4B 2198 10C9
Jabber: tl...@ja...
www   : http://ttys.homelinux.net

Re: [Tuxmath-devel] Git

[sasayins <sas...@gm...>]

Google Git Immersion, I love that site, step by step tutorials.





On Sun, Feb 6, 2011 at 6:04 PM, David Bruce <dav...@gm...>wrote:

> Hi,
>
> On Sun, Feb 6, 2011 at 9:52 PM, deepak aggarwal
> <dee...@gm...> wrote:
> > Hi
> > I want to know a good tutorial for learning GIT specially while working
> with
> > remote branches though I have learned all the basic steps and command
> while
> > working with local repository but I am not still confident that I can
> work
> > with remote branches.
>
> Google for "git community book" and "pro git book".  They cover
> everything you need to know for tux4kids (and lots more).  You can
> also just google for "git remote branch" - tons of info out there.
>
> David
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>

Re: [Tuxmath-devel] Git

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

Hi,

On Sun, Feb 6, 2011 at 9:52 PM, deepak aggarwal
<dee...@gm...> wrote:
> Hi
> I want to know a good tutorial for learning GIT specially while working with
> remote branches though I have learned all the basic steps and command while
> working with local repository but I am not still confident that I can work
> with remote branches.

Google for "git community book" and "pro git book".  They cover
everything you need to know for tux4kids (and lots more).  You can
also just google for "git remote branch" - tons of info out there.

David

[Tuxmath-devel] Git

[deepak a. <dee...@gm...>]

Hi
I want to know a good tutorial for learning GIT specially while working with
remote branches though I have learned all the basic steps and command while
working with local repository but I am not still confident that I can work
with remote branches.

Re: [Tuxmath-devel] [Tux4kids-tuxtype-dev] Help :(

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

On Sun, Feb 6, 2011 at 2:37 AM, Brendan Luchen <bm...@ri...> wrote:
> Hi Sajal,
> I'm copying the development lists. In addition to getting an alioth account,
> you'll need to be given write permission to the git repos, and I *think* you
> need to apply for it first via Alioth. Can someone confirm?

First you get an alioth account, then you request to join the tux4kids
project, and as soon as I approve it you can write to our project's
directory on the server, which means you can push changes directly
into the repos.

But for pre-GSoC purposes (e.g. studying the code, getting used to
git/automake/SDL/whatever), a read-only clone is perfectly sufficient.
 It is also possible to contribute very nicely by emailing patches
back for review, which is how almost all the Google Code-In work was
contributed.

Best,

David

Re: [Tuxmath-devel] Help :(

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

Hi Sajal,

I'm copying the development lists. In addition to getting an alioth account,
you'll need to be given write permission to the git repos, and I *think* you
need to apply for it first via Alioth. Can someone confirm?

What command are you using to clone? If you're using
git+ssh://your_username@................ try replacing it with simply git://
for a read-only copy.

HTH,
Brendan

On Fri, Feb 4, 2011 at 4:57 AM, Sajal Choudhary
<nig...@gm...>wrote:

> Hi Brendan
> I want to download the Tux4kids git repository. As mentioned at the website
> I made an alioth account. When cloning through terminal, it asks for the
> password thrice and then displays an error.
>
> Permission denied (publickey,keyboard-interactive).
> fatal: The remote end hung up unexpectedly
>
> Is there a special permission that I am not able to get. Please help.
>
> Thanks in advance
>
> -Sajal
>

Re: [Tuxmath-devel] Documentation

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

Hey Deepak,

The CMake chain for libt4k_common should be able to handle Doxygen out of
the box with (IIRC) `make doc` ...I'm not sure about TuxMath or the
Autotools chain, but if you're interested in Doxygentation it might be a fun
side-project to set them up for docs automation as well.

As for what to use in the source, pretty much ANY form you like is better
than nothing :) But Doxy is probable the best choice, yes.

Best,
Brendan

On Thu, Feb 3, 2011 at 3:20 PM, sasayins <sas...@gm...> wrote:

> Hi Deepak,
>
> Definitely you can used doxygen.
>
>
>
>
> On Thu, Feb 3, 2011 at 12:53 PM, deepak aggarwal <
> dee...@gm...> wrote:
>
>> Hi David
>> can you give me some tips about how should I do documentation of code in
>> source files and whether I can use doxygen for documentation.
>> and today I have requested for membership in your project please add me
>> quickly so that I can share my code with you.
>>
>>
>> ------------------------------------------------------------------------------
>> The modern datacenter depends on network connectivity to access resources
>> and provide services. The best practices for maximizing a physical
>> server's
>> connectivity to a physical network are well understood - see how these
>> rules translate into the virtual world?
>> http://p.sf.net/sfu/oracle-sfdevnlfb
>> _______________________________________________
>> Tuxmath-devel mailing list
>> Tux...@li...
>> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>>
>>
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
>
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>
>

Re: [Tuxmath-devel] Documentation

[sasayins <sas...@gm...>]

Hi Deepak,

Definitely you can used doxygen.




On Thu, Feb 3, 2011 at 12:53 PM, deepak aggarwal <dee...@gm...
> wrote:

> Hi David
> can you give me some tips about how should I do documentation of code in
> source files and whether I can use doxygen for documentation.
> and today I have requested for membership in your project please add me
> quickly so that I can share my code with you.
>
>
> ------------------------------------------------------------------------------
> The modern datacenter depends on network connectivity to access resources
> and provide services. The best practices for maximizing a physical server's
> connectivity to a physical network are well understood - see how these
> rules translate into the virtual world?
> http://p.sf.net/sfu/oracle-sfdevnlfb
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>
>

[Tuxmath-devel] Documentation

[deepak a. <dee...@gm...>]

Hi David
can you give me some tips about how should I do documentation of code in
source files and whether I can use doxygen for documentation.
and today I have requested for membership in your project please add me
quickly so that I can share my code with you.

Re: [Tuxmath-devel] Difference in the supposed and actual behavior when an answer corresponds to multiple questions

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

Hey Siddharth,


Can someone let me know if the problem is with the documentation or with the
> code? That would give me a start at contributing to the community.
>

The documentation is incorrect. We recently changed the behaviour of this
situation in response to news that some kids would focus on the comet above
and then be confused when it did not get destroyed--instead, it's now a sort
of bonus shot. The readme should be updated, and you're more than welcome to
do so if you like :)

Thanks,
Brendan



> Thanks,
> Siddharth
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
>
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>
>

[Tuxmath-devel] Difference in the supposed and actual behavior when an answer corresponds to multiple questions

[Siddharth K. <sid...@gm...>]

Hi everyone,

I would first like to introduce myself to the tux4kids community. My name is
Siddharth Kothari and I am a 2nd year undergraduate computer science
student.

I downloaded tuxmath from the git repository a couple of days back. While
going through the README.txt file, I saw a *note *under the HOW TO PLAY
section which says:
"*Note: Sometimes more than one comet will have the same answer.  In this
case, the lowest comet will be destroyed.*" However, when I am playing the
game and I see that my answer corresponds to more than one comets, all of
them get destroyed (I have seen this happening in Math_Training_Academy, and
the Fleet_Missions). To verify this, one can look at the "void
game_handle_answer(void)" function of the "game.c" file.

Consider a scenario where there are two comets: 5*2 = ? and 23-13 = ?. A
player gives the answer "10" after seeing the first one. But instead, both
of them get shot though he may not have calculated the 2nd comet's answer.
In my opinion, such situations give a player an unfair advantage.

Can someone let me know if the problem is with the documentation or with the
code? That would give me a start at contributing to the community.

Thanks,
Siddharth

Re: [Tuxmath-devel] [Tux4kids-discuss] Help needed on a function

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

Hi,

On Wed, Feb 2, 2011 at 2:52 PM, deepak aggarwal
<dee...@gm...> wrote:
> Hi David
> I am able to do so i.e by converting arguments into string and then
> converting them back by simply loading these function from a dynamic library
> but my main concern is that all the libraries which we use are written for
> Linux environment and when we port them to different platform then we might
> face problem.
> Please comment on it.

What libraries/platforms are you concerned about?  Everything we use
is supported on Linux, *BSD, OS-X, and Windows.  We also try to
support BeOS/Haiku as much as possible.  There, we are limited by the
lack of SDL_Pango and librsvg2.  There are configure options to
deactivate the use of these libraries for this reason (and for
testing).  I haven't tried building without these libraries in a
while.

Also, I'm not sure what you mean by "converting arguments by simply
loading the function from a dynamic library".

btw, I don't think you've requested to join our project on Alioth yet.
 You need to do this if you want to contribute.

Thanks,

David