tuxmath-devel — TuxMath developer's mailing list.

[Tuxmath-devel] Tux4Kids - call for GSoC 2011 mentors

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

Hi,

Organization applications for GSoC are due in one week.  If we are
going to participate this year, we need to figure out who can serve as
mentor.  As far as I'm concerned, the following people could be
mentors:

1. Any previous GSoC student or mentor
2. Any other developer for Tux Paint, Tux Math, or Tux Typing who has
contributed code on at least several occasions.

Regarding the GCI students, at least two of you seem to be advanced
enough coders, but it would be rather awkward to have a secondary
school student serving as a mentor for a university student (although
I believe the rules do allow it).

No one else has expressed any interest in being the GSoC admin.  I
guess I can do it again, as long as others step forward to be mentors.

Regarding project ideas, I think we should stick with things that
either fix existing open issues, or add very self-contained
significant features (e.g. a new math or typing mini-game).  I don't
want to have GSoC projects result in unfinished business at the end of
the summer.

Replies are welcome with:
1. Offers to serve as mentor
2. Ideas for GSoC projects.

Best,

David Bruce

Re: [Tuxmath-devel] Informação Tux Math

[<vic...@gm...>]

Oi Luana,

Tux4kids é um projeto de software livre educacional que inclui atualmente 4
jogos: TuxMath, TuxPaint, TuxType e TuxHistory.

Eu participo desta lista a um pouco mais de um ano e posso te citar algumas
coisas legais que vi, mas não sei das razões iniciais deste projeto.
Acredito que difundir o Unix entre professores e alunos era um dos
objetivos.

De qualquer forma, aconselho você fazer suas perguntas em inglês pois os
mais antigos nesse projeto, pelo que sei, não falam português.

(PS: Software educacional ou relacionado a educação ? Trabalhei com o
TelEduc por mais de 1 ano, totalmente brasileiro ^^).


2011/2/11 luana souza <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
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>
>


-- 
----------------
Victor Toso

Re: [Tuxmath-devel] Connection between servers.

[<vic...@gm...>]

Sorry, I just saw the other thread about SDL networking library and the
reply from David.

I'm thinking about it...

On Thu, Mar 3, 2011 at 11:50 PM, vic...@gm...
<vic...@gm...>wrote:

> Hi Deepak, David,
>
> The servers in Tux Math has the goal to connect players ? Once the
> connections between them is achieved, they play using TCP/IP without
> interference of the server ?
>
> Also, is this being done at Tux Math code or t4kcommon ? (thinking about
> some sort of Tux Type multiplayer game :) )
>
> regards,


-- 
----------------
Victor Toso

Re: [Tuxmath-devel] Connection between servers.

[<vic...@gm...>]

Hi Deepak, David,

The servers in Tux Math has the goal to connect players ? Once the
connections between them is achieved, they play using TCP/IP without
interference of the server ?

Also, is this being done at Tux Math code or t4kcommon ? (thinking about
some sort of Tux Type multiplayer game :) )

regards,

On Mon, Feb 14, 2011 at 2:03 PM, David Bruce <dav...@gm...>wrote:

> Hi Deepak,
>
> On Mon, Feb 14, 2011 at 3:25 PM, deepak aggarwal
> <dee...@gm...> wrote:
> > Hi david just start working on a prototype( sketch) on how servers
> connect
> > to each other and how they connect. Till now i am thinking of peer to
> peer
> > communication between servers as it is fault tolerance and easy to
> implement
> > and sync. What's your thought on it ?
>
> I don't really have a clear idea of what you are trying to do.  I
> checked out your branch, and there weren't any commits in it (from the
> point it was branched from master).
>
> I don't understand the idea of "multiple servers", either.
>
> Regards,
>
> David
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>



-- 
----------------
Victor Toso

Re: [Tuxmath-devel] Rendering issues during resizing of screen

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

Hi David,


> I just did a "git pull", and I don't don't think I see that commit,
> although it looks like you fixed something else that I was trying to
> track down. Is this commit the one?
>

The commit is in the t4kcommon repository.

Thanks,
Siddharth

On Fri, Feb 25, 2011 at 6:02 AM, David Bruce <dav...@gm...>wrote:

> Hi Siddarth,
>
> On Thu, Feb 24, 2011 at 2:18 PM, Siddharth Kothari
> <sid...@gm...> wrote:
> > Hi David,
> >
> >> So does it work correctly now? (I'm just checking mail from a work
> >> computer right now so I can't test it).  Thanks for addressing this.
> >
> > Yes, it does.
>
> I just did a "git pull", and I don't don't think I see that commit,
> although it looks like you fixed something else that I was trying to
> track down. Is this commit the one?
>
> dbruce@emperor:/usr/local/src/git/tuxmath$ git log
> commit 26effbf0da58764c916b19d476d742deda9ed8ff
> Author: Siddharth <sid...@gm...>
> Date:   Thu Feb 24 00:24:58 2011 +0530
>
>     Adding a check if the list is null to prevent segfault
>
> From the commit message and the fact that it only involves
> src/mathcards.c, it sounds like a fix for something else.
>
> Thanks,
>
> David
>

Re: [Tuxmath-devel] Rendering issues during resizing of screen

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

Hi Siddarth,

On Thu, Feb 24, 2011 at 2:18 PM, Siddharth Kothari
<sid...@gm...> wrote:
> Hi David,
>
>> So does it work correctly now? (I'm just checking mail from a work
>> computer right now so I can't test it).  Thanks for addressing this.
>
> Yes, it does.

I just did a "git pull", and I don't don't think I see that commit,
although it looks like you fixed something else that I was trying to
track down. Is this commit the one?

dbruce@emperor:/usr/local/src/git/tuxmath$ git log
commit 26effbf0da58764c916b19d476d742deda9ed8ff
Author: Siddharth <sid...@gm...>
Date:   Thu Feb 24 00:24:58 2011 +0530

     Adding a check if the list is null to prevent segfault

>From the commit message and the fact that it only involves
src/mathcards.c, it sounds like a fix for something else.

Thanks,

David

Re: [Tuxmath-devel] Rendering issues during resizing of screen

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

Hi David,

So does it work correctly now? (I'm just checking mail from a work
> computer right now so I can't test it).  Thanks for addressing this.
>

Yes, it does.


Thanks,
Siddharth



On Thu, Feb 24, 2011 at 12:02 PM, David Bruce <dav...@gm...>wrote:

> Hi Siddarth,
>
> On Wed, Feb 23, 2011 at 5:58 PM, Siddharth Kothari
> <sid...@gm...> wrote:
> > Hi everyone,
> >
> > When one exits a custom game and resizes the screen, the rendering of the
> > buttons on the screen does not happen properly. I suppose this problem is
> > not local.
> >
> > To fix this, I used a T4K_PrerenderAll() call whenever a resizing of the
> > screen happens. I have committed this change.
>
> So does it work correctly now? (I'm just checking mail from a work
> computer right now so I can't test it).  Thanks for addressing this.
>



>
> > Earlier, this call was used in the T4K_RunMenu. But I think we are now
> > dealing with F10 key press in a different way and the previous code is
> > commented out. Can someone verify if they were also facing this issue?
>
> Hopefully Brendan is reading this - the current handling of resizing
> is fairly complicated, and if I understand correctly depends on
> registering an appropriate callback function to be invoked with F10
> (as part of T4K_HandleStandardEvents() or whatever its called).  So
> when we go from the menu to a game or vice versa, the callback needs
> to be updated.
>
> So far, I haven't quite studied this part of the code enough to feel I
> understand it all the way to the bottom.
>
> David
>

Re: [Tuxmath-devel] Rendering issues during resizing of screen

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

Hi Siddarth,

On Wed, Feb 23, 2011 at 5:58 PM, Siddharth Kothari
<sid...@gm...> wrote:
> Hi everyone,
>
> When one exits a custom game and resizes the screen, the rendering of the
> buttons on the screen does not happen properly. I suppose this problem is
> not local.
>
> To fix this, I used a T4K_PrerenderAll() call whenever a resizing of the
> screen happens. I have committed this change.

So does it work correctly now? (I'm just checking mail from a work
computer right now so I can't test it).  Thanks for addressing this.

> Earlier, this call was used in the T4K_RunMenu. But I think we are now
> dealing with F10 key press in a different way and the previous code is
> commented out. Can someone verify if they were also facing this issue?

Hopefully Brendan is reading this - the current handling of resizing
is fairly complicated, and if I understand correctly depends on
registering an appropriate callback function to be invoked with F10
(as part of T4K_HandleStandardEvents() or whatever its called).  So
when we go from the menu to a game or vice versa, the callback needs
to be updated.

So far, I haven't quite studied this part of the code enough to feel I
understand it all the way to the bottom.

David

[Tuxmath-devel] Rendering issues during resizing of screen

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

Hi everyone,

When one exits a custom game and resizes the screen, the rendering of the
buttons on the screen does not happen properly. I suppose this problem is
not local.

To fix this, I used a T4K_PrerenderAll() call whenever a resizing of the
screen happens. I have committed this change.

Earlier, this call was used in the T4K_RunMenu. But I think we are now
dealing with F10 key press in a different way and the previous code is
commented out. Can someone verify if they were also facing this issue?

Thanks,
Siddharth

Re: [Tuxmath-devel] Tux4Kids in GSoC 2011 - anyone interested?

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

Hi David and all!

I think it is a very important moment in our project. You are true
when say that we shall get stable our projects before we begin new
feautures. Sadly, many of us don't have all the time we want to invest
in tux4kids. If we participate this year, we should be very strict in
the aplications we will accept. And if we decide not to participate
this year we should put a list of goals to do.

2011/2/21 David Bruce <dav...@gm...>:
> Hi,
>
> The application period for projects interested in GSoC opens Feb 28.
> Are any of the previous mentors interested in being GSoC admin for
> Tux4Kids this year?  I've done it the last two years, and would be
> more than happy if someone else wants to take over.  I love working on
> this stuff, but it is an increasing source of unhappiness for those
> around me, who view all this as me "playing on the computer again".
> So, I really don't want to be GSoC admin anymore.
>
> Also, speaking to the Tux Math and Tux Typing side, we have a ton of
> unfinished business up in the air.  I'm not sure it even makes sense
> to participate in GSoC this year.  It seems we start all these
> ambitious projects which get partially done, but never quite come to
> fruition.
>
> Tux4Kids-admin?
> Tux History?
> Tux Typing has basically ground to a halt because we were waiting to
> get the t4k_common library shaped up (actually, that might be a GSoC
> project that would make sense - "port" tuxtype to use t4k_common).
>
> We haven't released a build of TuxMath for the Mac in almost 2 years.
> We haven't released a build of TuxType for Mac in over 3 years!
>
> The current version of tuxmath that uses t4k_common isn't packaged for
> any distro, AFAIK.
>
> We added a ton of cool features to tuxmath during Google Code-In
> (which, I may add, was massively time-consuming and got my family
> really mad at me), but most of them left various loose ends which need
> to be finished before a public release can be made.  We haven't even
> gotten that out the door, and folks are clamoring to do more big
> changes to the program ("I'm going to rewrite mathcards from scratch".
>  "I'm going to put in a new event architecture that will completely
> break the existing LAN game".  "Let's remove all the network code and
> rewrite everything from scratch."  "Let's move the entire program to
> C++").  I think these are the last things we should be considering at
> this point.
>
> Sorry about the rant, but I'm getting more and more convinced that the
> project is suffering from GSoC-induced bloat.  If we are going to take
> part again, we should tightly restrict the number of participants, and
> make certain that the projects don't lead to even more unfinished
> business.
>
> David
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>



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

[Tuxmath-devel] Tux4Kids in GSoC 2011 - anyone interested?

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

Hi,

The application period for projects interested in GSoC opens Feb 28.
Are any of the previous mentors interested in being GSoC admin for
Tux4Kids this year?  I've done it the last two years, and would be
more than happy if someone else wants to take over.  I love working on
this stuff, but it is an increasing source of unhappiness for those
around me, who view all this as me "playing on the computer again".
So, I really don't want to be GSoC admin anymore.

Also, speaking to the Tux Math and Tux Typing side, we have a ton of
unfinished business up in the air.  I'm not sure it even makes sense
to participate in GSoC this year.  It seems we start all these
ambitious projects which get partially done, but never quite come to
fruition.

Tux4Kids-admin?
Tux History?
Tux Typing has basically ground to a halt because we were waiting to
get the t4k_common library shaped up (actually, that might be a GSoC
project that would make sense - "port" tuxtype to use t4k_common).

We haven't released a build of TuxMath for the Mac in almost 2 years.
We haven't released a build of TuxType for Mac in over 3 years!

The current version of tuxmath that uses t4k_common isn't packaged for
any distro, AFAIK.

We added a ton of cool features to tuxmath during Google Code-In
(which, I may add, was massively time-consuming and got my family
really mad at me), but most of them left various loose ends which need
to be finished before a public release can be made.  We haven't even
gotten that out the door, and folks are clamoring to do more big
changes to the program ("I'm going to rewrite mathcards from scratch".
 "I'm going to put in a new event architecture that will completely
break the existing LAN game".  "Let's remove all the network code and
rewrite everything from scratch."  "Let's move the entire program to
C++").  I think these are the last things we should be considering at
this point.

Sorry about the rant, but I'm getting more and more convinced that the
project is suffering from GSoC-induced bloat.  If we are going to take
part again, we should tightly restrict the number of participants, and
make certain that the projects don't lead to even more unfinished
business.

David

[Tuxmath-devel] FIXME in set_current_bkg of titlescreen.c

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

Hi,

/* FIXME this function assumes the background is properly scaled */
> /* Also, it only sets the image for the current resolution, not  */
> /* the "other" one.                                              */
> void set_current_bkg(SDL_Surface* new_bkg)
>

This FIXME is *not relevant* since the function set_current_bkg(SDL_Surface*
new_bkg) never gets called.

This function is called only by RenderTitleScreen() function of
titlescreen.c file, and the call happens only when the following condition
is true:

if(current_bkg()->w != T4K_GetScreen()->w || current_bkg()->h !=
> T4K_GetScreen()->h)
>

which is something that would not happen.

Can some one verify this? Or correct me if I am wrong.

Thanks,
Siddharth

Re: [Tuxmath-devel] Networking library

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

Hi,

On Wed, Feb 16, 2011 at 2:15 PM, deepak aggarwal
<dee...@gm...> wrote:
> Hi David
> I have recently hear about a networking library on sdl mailing list. There
> they have said that this library has been used in many games. You might want
> to check it out.
> Here's the link
> http://enet.bespin.org/

I'm on the SDL list, so I saw your mailing.  I took a brief look at it
- it was written for a FPS game that uses UDP rather than TCP, because
FPS games require a lot of speed but don't care much about dropped
packets (most of the data is obsoleted by the next frame anyway).  So
I'm not sure it fits our needs so well.

More importantly, from a practical standpoint, we ought to use libs
that are included in Debian and other distros, as well as our
cross-platform setups (mingw-cross-env and MacPorts).

I looked at your diagram, and your prototype code, and unfortunately I
have no idea what you are trying to accomplish.

IMHO, our current "server" arrangement has the following limitations:
1. Each server instance can only support one math game at time.
2. Only one server instance can be run on a machine at a time.  This
can be done either in a thread from within the overall tuxmath
program, or as a standalone program.
3. When run as a standalone program, the server only runs the
compile-time defaults for the lesson settings.  There is no way to
change the lesson.  So the pthreads way is strongly preferred.
Fortunately, linux/OSX/mingw/BeOS/Haiku all provide thread support.

Now there have been comments that "the server is hopelessly broken and
should be rewritten", but I have yet to see any clear reasons why this
is the case.  It seems to be more a desire to write some elite
multithreaded/multiport server program, than anything to serve the
needs of actual users.  I have yet to have user say "the LAN game is
fun, but I wish the server supported multiple simultaneous games".

Now, on the client side, I think we have more problems.  The network
code (that is, all the calls to SDL_net functions) is supposed to be
confined to network.c/h, and I think that is the case.  Also, I think
game.c communicates with the server reasonably cleanly via the
functions in network.c/h (the ones prefixed with "LAN_").

But the server detection and game-joining is spread through four big
functions (run_lan_join(), LAN_DetectServers(), detecting_servers(),
Ready(), and Standby() in menu.c, network.c, and highscore.c).  I
think the biggest issue is that each of these functions runs its own
loop to detect network events, and there isn't any provision to
correctly handle unexpected messages or socket disconnection.  Thus,
we have a lot of "corner cases" where the client gets confused and
deadlocks or segfaults if the server connection is lost.  They won't
show up if the game is used as intended, but it isn't to hard to
deliberately cause crashes. I've started to try to fix some of these,
but this code does seem to be in need of more extensive overhaul.  In
other words, I agree we really do need a better "event system".

Just to be clear, the only reason server.c/h is compiled into tuxmath
itself is to support the running of the server inside a thread.  There
isn't supposed to be any code in those files that is needed by the
client per se.  I can see, however, that this might be confusing to
users.  Perhaps we should build and package the server and client
separately.  I think it would be pretty easy, and hopefully useful, to
create "--client-only" and "--server-only" options for configure.  The
"--client-only" version wouldn't use server.c/h, whereas
"--server-only" would eliminate factoroids.c and game.c.  Adjusting
the menus ought to be pretty easy because they are generated at run
time from the xml files.

Thoughts?

David

[Tuxmath-devel] Networking library

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

Hi David
I have recently hear about a networking library on sdl mailing list. There
they have said that this library has been used in many games. You might want
to check it out.
Here's the link
http://enet.bespin.org/

[Tuxmath-devel] Fwd: Informação Tux Math

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

Hi all!

I resend a message.


---------- Forwarded message ----------


Good Afternoon,

Am Luana, attending the 4th year of Information Systems, working on a>
Computer Laboratory in a municipal school,
I contacted voceis why I'm doing my thesis on "The Use of Educational
Software Tux Math as a resource for teaching
and learning in mathematics classes. "I have been researching this
educational software and have not found hardly anything,
I would like help from me in voceis informs the source, the Why, the
developers of this game.
Congratulations on creating is a very good game to teach math

I thank everyone's understanding.
att,



Luana Souza
City: Rondonopolis-MT

Re: [Tuxmath-devel] Connection between servers.

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

Hi Deepak,

On Mon, Feb 14, 2011 at 3:25 PM, deepak aggarwal
<dee...@gm...> wrote:
> Hi david just start working on a prototype( sketch) on how servers connect
> to each other and how they connect. Till now i am thinking of peer to peer
> communication between servers as it is fault tolerance and easy to implement
> and sync. What's your thought on it ?

I don't really have a clear idea of what you are trying to do.  I
checked out your branch, and there weren't any commits in it (from the
point it was branched from master).

I don't understand the idea of "multiple servers", either.

Regards,

David

[Tuxmath-devel] Connection between servers.

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

Hi david just start working on a prototype( sketch) on how servers connect
to each other and how they connect. Till now i am thinking of peer to peer
communication between servers as it is fault tolerance and easy to implement
and sync. What's your thought on it ?

Re: [Tuxmath-devel] TuxMath

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

Hi Aviral,

On Mon, Feb 14, 2011 at 1:25 PM, Aviral Dasgupta <avi...@gm...> wrote:
> Hi.
> I had some time today, after my exam, so I had a good look at TuxMath, and
> the LAN Server. Here are a few things that I want to point out:
>
> XXX Bug #1: The StopServer method will only work if you're running the
> server using pthread_create and not if you're using system. It currently
> works by setting a (local) flag, which will obviously not work with system,
> as the server will be running on another process altogether.

Don't have time to test it right now, but I'm pretty sure that
StopServer() works both ways.  The "quit" flag is in the scope of
server.c, which is where RunServer() is, so it ought to work.

> XXX Bug #2: The server's sending out a "flurry-of-questions" when the game
> starts, but works fine otherwise. Implementing logic similar to that in the
> non-LAN game should fix this.

That's leftover from our initial design where the client had a queue
of questions to pull from, and the server refilled it as needed.  It
turned out that it was difficult/impossible to keep the clients
tightly synchronized.  So a couple of weeks ago I got rid of the
"queue" in game.c, so now the comets appear immediately when a new
question is received from the server.  I must have forgotten to get
rid of the initial question load.  However, the server is still
supposed to send enough questions to supply the number of comets that
are supposed to appear on the screen initially, with a brief interval
between each.

> It would be *kinda good* to have a bug tracker. Has the project ever
> considered having a *proper* one?

Like many other things, considered but "just haven't gotten around to it".

> I can't reproduce the bug that you were (David was) talking about
> yesterday(?); the one in which a server would "reply" that a game was still
> in progress even after all the players had left.
>
> I don't want to sound pessimistic, but the current system seems hopelessly
> broken. I think we should try and fix these bugs, push out a new release,
> and rewrite the entire thing from scratch. I'm working on Bug #1: I think
> the best solution would be to add another message to make the server quit.

See above.  But I don't think we should let the clients shut down the server.

David

[Tuxmath-devel] TuxMath

[Aviral D. <avi...@gm...>]

Hi.

I had some time today, after my exam, so I had a good look at TuxMath, and
the LAN Server. Here are a few things that I want to point out:

   1. *XXX* Bug #1: The *StopServer* method will only work if you're running
   the server using *pthread_create* and not if you're using *system*. It
   currently works by setting a (local) flag, which will obviously not work
   with *system*, as the server will be running on another process
   altogether.
   2. *XXX* Bug #2: The server's sending out a "flurry-of-questions" when
   the game starts, but works fine otherwise. Implementing logic similar to
   that in the non-LAN game should fix this.
   3. It would be **kinda good** to have a bug tracker. Has the project ever
   considered having a *proper* one? (not an empty one)
   4. I can't reproduce the bug that you were (David was) talking about
   yesterday(?); the one in which a server would "reply" that a game was still
   in progress even after all the players had left.

I don't want to sound pessimistic, but the current system seems hopelessly
broken. I think we should try and fix these bugs, push out a new release,
and rewrite the entire thing from scratch. I'm working on Bug #1: I think
the best solution would be to add another message to make the server quit.
(I think this already exists; we just need to use it ["quit"] instead of the
flag)

-- 
Regards,
Aviral

Re: [Tuxmath-devel] Documentation

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

Hi,

On Sun, Feb 13, 2011 at 10:34 AM, deepak aggarwal
<dee...@gm...> wrote:
> Hey are we using doxygen for documentation because when i try doxygebn on
> tux common library then i am able to get breif description.of all functions.

t4k_common uses Doxygen.  We haven't yet used it anywhere else.

David

[Tuxmath-devel] Documentation

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

Hey are we using doxygen for documentation because when i try doxygebn on
tux common library then i am able to get breif description.of all functions.

Re: [Tuxmath-devel] Server-related Bug

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

Hi Aviral,

On Sat, Feb 12, 2011 at 10:04 PM, Aviral Dasgupta <avi...@gm...> wrote:
> It appears that a bug was introduced either in
> commit b02dbf3175315b77454a931750650617054f3b6e, or
> in d22fdf8984d2f61edee5ce80c6de3c1c5e5712de, due to which the game says that
> the server isn't running, whereas it actually is.

Hmm, have to check that.  The "Stop Server" feature only refers to a
server thread running as part of that same instance of Tux Math.  If a
server is running on another instance of Tux Math on the same machine,
or on another machine on the network, that function will not report
that it is running.

On a related note, I think I fixed the "de-init from server stop bug",
but I found that the server doesn't properly register when a game ends
due to all the clients quitting.  It does correctly report that a game
is not in progress if a game is completed (all questions answered, or
lost).

So the LAN game is shaping up, but there are still some more bugs to
kill before a release.

David

[Tuxmath-devel] Server-related Bug

[Aviral D. <avi...@gm...>]

It appears that a bug was introduced either in commit *
b02dbf3175315b77454a931750650617054f3b6e*, or in *
d22fdf8984d2f61edee5ce80c6de3c1c5e5712de*, due to which the game says that
the server isn't running, whereas it actually is.

-- 
Regards,
Aviral

Re: [Tuxmath-devel] Server prototype

[Aviral D. <avi...@gm...>]

Hi, Deepak,

Just wanted to let you know that I'm working on a new events system which
will eventually replace the current messages system.

-- 
Regards,
Aviral

[Tuxmath-devel] Server prototype

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

Hi David
 I have just added my files under a remote branch server_deepak . Hope
you like how i implement it. Thought i is still in initial stage but
it gave clear idea what i want to implement.

I have been working for many days inorder to make a prototype how
server contact with clients and other server but not able to find a
solution yet. Can you suggest me a way how i can design it.
And please tell me other person who are working on it or using it for
multi-player. I want to feature that they are missing.