tuxmath-devel — TuxMath developer's mailing list.

Re: [Tuxmath-devel] po/ conflicts

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

>> I wasn't aware of any issues with po or gmo files in tuxtype.
>
> I wish I'd paid closer attention to the complaints I got...most
> recently (though not actually merge-related) make complained about a
> missing zh_CN.po that's listed in LINGUAS but not present in po/ so I
> just deleted the line in LINGUAS from my working copy.

FWIW, I discovered the other issue I was having is likely a
TortoiseGit bug. Basically it wasn't letting me branch or merge on
Windows unless I used --force because of "local changes" to some of
the .po files that were really just being read as CRLF.

-Brendan

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

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

> I personally would favor going to 0.18, but I may be biased because
> that is what is on my main home desktop.
>
> Thoughts?

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

Also, it apparently won't let me configure at all without a version
declared--at least, I think that's why. Automake fails and won't
create config.rpath (on Fedora with AC version 2.63, and automake
version 1.11.1). I'm currently using 0.17 and added the line back
locally for now. So, I'm decidedly not biased :)

-Brendan

Re: [Tuxmath-devel] Libxml2 in Tux4kids

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

Hi Michal,

2010/6/21 Michał Świtakowski <tux...@sw...>:
> Hi,
>
> We decided with Vikas to use XML for lesson files generated by tux4kids-admin
> and read by TM and TT. To make parsing those files easier Vikas uses libxml2
> library which will be introduced in tux4kids. I wonder if we should make it possible
> to compile our games without support for tux4kids-admin and consequently without libxml2.
> I think about SCHOOL_MODE macro and set of
>
> #ifdef SCHOOL_MODE
> ...
> #endif
>
> conditions in the code. SCHOOL_MODE could be enabled/disabled by autotools
> with configure script if I'm right. Do you think we should do it that way?

Yes, we can certainly support optional use of libraries at configure
time in configure.ac - we do that already with several things
(SDL_Pango, SDL_net, librsvg2, and also libt4k_common) with flags like
"--without-sdlpango".  By default, autotools gives us preprocessor
macros such as "HAVE_SDL_PANGO" to allow C code to behave
appropriately, but we can use whatever macros we want in case
"SCHOOL_MODE" turns out to be not quite identical with "HAVE_XML2".

David

Re: [Tuxmath-devel] [Tux4kids-tuxtype-dev] Woo hoo! - Tux4Kids now #1 Alioth project for downloads

[Vikas S. <vik...@gm...>]

That's great news!
-- 
Regards ,
Vikas Singh

[Tuxmath-devel] Woo hoo! - Tux4Kids now #1 Alioth project for downloads

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

Hi everyone,

Just a happy announcement - as of today, we have passed minicom to
take over the top of the standings for most downloads for
Alioth-hosted projects!  Of course, we also have a similar amount of
downloads from SF.net, and most of our users undoubtably get Tux Math
and Tux Typing from their Linux distributions.

(OTOH, we likely have no more than 10% of the download volume of Tux Paint)

Cheers,

David

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

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

Hi,

Basically, the latest gettext is 0.18, which is in Debian Sid
(unstable) but not yet in testing, stable, or any Ubuntu release.  I
doubt it is in many other distros yet, either.  It is, however, in
mingw-cross-env as well as MacPorts.  It turns out that we all should
use the same gettext version to avoid build and runtime errors.
Contrary to what I thought, it is considered unsafe to use more than
one version.

So, we are going to have to move to gettext-0.18 in the fairly near
future.  If we go ahead now, it would force some of us to install a
newer gettext outside of the usual package manager.  If we wait, we
might delay being able to work on the cross-platform builds.

To the best of my knowledge, this doesn't affect end-users, just the
devs actually working on our programs.

I personally would favor going to 0.18, but I may be biased because
that is what is on my main home desktop.

Thoughts?

David


---------- Forwarded message ----------
From: Bruno Haible <br...@cl...>
Date: Sun, Jun 20, 2010 at 10:24 AM
Subject: Re: gettext 0.18 creating po/Makefile.in.in with wrong
GETTEXT_MACRO_VERSION
To: David Bruce <dav...@gm...>
Cc: bug-gnu-gettext <bug...@gn...>, sa...@de...


Hi,

David Bruce wrote:
> Can I safely leave this line out to allow the program to be built with
> either 0.17 or 0.18?

Not safely. You can do it, but the result would not be safe. Please read
the chapter "Integrating with CVS" at
 <http://www.gnu.org/software/gettext/manual/html_node/CVS-Issues.html>

Bruno

Re: [Tuxmath-devel] po/ conflicts

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

Hi,

> btw, I stumbled what appears to be a bug in the newest gettext (0.18)
> in Debian Sid.  When you run "autopoint" (which is part of
> "autoreconf"), it creates po/Makefile.in.in that still lists version
> 0.17, causing a version mismatch error.  I filed a bug report.

Basically, it isn't a bug, or at most is a "bug" consisting of an
ambiguity in the gettext documentation.  Tuxtype had the following in
configure.ac:

AM_GNU_GETTEXT_VERSION([0.17])

I had thought this meant a minimum version, but it creates a
requirement for the version to be exactly 0.17.  Although Autoconf
complains if this macro is omitted, it is not required, and apparently
we just need to leave it out if we are to be able to work on tuxtype
with either gettext 0.17 or 0.18.

Best,

David

Re: [Tuxmath-devel] po/ conflicts

[Holger L. <ho...@la...>]

Hi David,

On Sonntag, 20. Juni 2010, David Bruce wrote:
> btw, I stumbled what appears to be a bug in the newest gettext (0.18)
> in Debian Sid.  When you run "autopoint" (which is part of
> "autoreconf"), it creates po/Makefile.in.in that still lists version
> 0.17, causing a version mismatch error.  I filed a bug report.

which number?


cheers,
	Holger

Re: [Tuxmath-devel] po/ conflicts

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

Hi,

I think I have the po/gmo issues fixed in git for both tuxmath and
tuxtype, AFAICT.

btw, I stumbled what appears to be a bug in the newest gettext (0.18)
in Debian Sid.  When you run "autopoint" (which is part of
"autoreconf"), it creates po/Makefile.in.in that still lists version
0.17, causing a version mismatch error.  I filed a bug report.

So, if you have gettext-0.18 with this issue, you will have to manually change:

GETTEXT_MACRO_VERSION = 0.17

to:

GETTEXT_MACRO_VERSION = 0.18

until this bug is fixed.

Cheers,

David

Re: [Tuxmath-devel] po/ conflicts

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

Hi Bill and John,

> FYI Tux Paint doesnt include libintl stuff in its codebase.
> We do have our own (patched?) builds of same for Windows, IIRC.
>
> John P might be able to explain our situation. Cc'ing.
>

We won't need the internal libintl directory for the Windows
crossbuild once the remaining snags for the mingw-cross-env based
build are worked out.

I would indeed like to get John's native Windows environment set up,
or at least have someone in our project set it up.  However, I don't
have windows at home, and I don't really have full control of my win32
box at work - or at any rate I'm not supposed to have full control of
it ;)

There are some places where tuxmath and tuxtype will likely break in a
native build due to paths not matching up to how they are set in the
crossbuild.  In other words, if you do a "make" and "make install",
the resulting installation probably won't work.  However, I don't see
any reason why we couldn't do "make" and then "make nsis" (the target
used to create the NSIS win32 installer using our current crossbuild)
on windows, and then execute the resulting installer to install the
program.

David

Re: [Tuxmath-devel] po/ conflicts

[Bill K. <nb...@so...>]

On Fri, Jun 18, 2010 at 08:49:46PM -0500, David Bruce wrote:
> 
> Basically, intl/ is a self-contained copy of gnu libintl that contains
> all the code needed for gettext to operate.  It is preferred by
> distros that programs use the system's libintl rather than duplicating
> code, and I think that is how it builds with autotools for linux.  The
> self-contained intl/ directory is there to simplify builds for other
> platforms.   If we reliably have libintl available on every platform
> we want to support, we could eliminate the bundled one.

On phone, so being brief

FYI Tux Paint doesnt include libintl stuff in its codebase.
We do have our own (patched?) builds of same for Windows, IIRC.

John P might be able to explain our situation. Cc'ing.

-b!

Re: [Tuxmath-devel] po/ conflicts

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

> Well, I think I caused some of it by adding a Mongolian po file to two
> different branches in tuxmath, then trying to merge the branches,
> resulting in a file with conflicts.  I've been pretty wiped out from
> work the last few days, but tomorrow I should have time to get it
> straightened out.  IIRC, tuxmath's "master" is OK but
> "commonification" has the corrupted file.

Right, I did several ugly manual merges before actually finding (one
of) the original file via git's web client, and committing that!

> I wasn't aware of any issues with po or gmo files in tuxtype.

I wish I'd paid closer attention to the complaints I got...most
recently (though not actually merge-related) make complained about a
missing zh_CN.po that's listed in LINGUAS but not present in po/ so I
just deleted the line in LINGUAS from my working copy.

Best,
Brendan

Re: [Tuxmath-devel] po/ conflicts

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

Hi Brendan,

On Fri, Jun 18, 2010 at 4:36 PM, Brendan Luchen <che...@gm...> wrote:
> Hey David,
>
> I've been having some nasty problems with merge conflicts popping up
> in po/ in both TuxType and TuxMath, even though I haven't been
> touching those directories. It doesn't seem like any of the .po files
> are being generated, either; am I mistaken? Could you give a rundown
> of the interplay between gettext and the stuff in po/ and intl/ for
> our projects, or point me to some literature? Hoping I haven't stomped
> anything with all this merging.

Well, I think I caused some of it by adding a Mongolian po file to two
different branches in tuxmath, then trying to merge the branches,
resulting in a file with conflicts.  I've been pretty wiped out from
work the last few days, but tomorrow I should have time to get it
straightened out.  IIRC, tuxmath's "master" is OK but
"commonification" has the corrupted file.

I wasn't aware of any issues with po or gmo files in tuxtype.

Basically, intl/ is a self-contained copy of gnu libintl that contains
all the code needed for gettext to operate.  It is preferred by
distros that programs use the system's libintl rather than duplicating
code, and I think that is how it builds with autotools for linux.  The
self-contained intl/ directory is there to simplify builds for other
platforms.   If we reliably have libintl available on every platform
we want to support, we could eliminate the bundled one.

po/ is where the message catalogs for the various translations are
located.  The *.po files are the human-readable form, and the *.gmo
files are the optimized machine-readable counterparts that are
actually used at runtime.  The *.gmo files get made, IIRC, when "make
update-po" is run within the po directory.  This doesn't happen with
an ordinary "make", but does occur as part of "make dist".

To the best of my knowledge, the gettext manual has the most complete
description of this stuff.

http://www.gnu.org/software/gettext/manual/gettext.html


HTH,

David

[Tuxmath-devel] PNG cache stored in user data dir now

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

Hi all,

I have fixed the code to store PNG cache files under user's tuxmath
data dir, e.g. /username/.tuxmath/caches. The git repository is
updated.

Moreover, if for any reason the cache file is not created, the program
just gives up caching, instead of generating a segfault :=). Any
feedbacks are welcome!

Cheers
Wenyuan

Re: [Tuxmath-devel] Including libxml2-devel library

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

David Bruce <dav...@gm...> schrieb:
> Volker Grabsch <vo...@no...> schrieb:
> >
> > Just a quick guess, without having tested it:
[...]
> > Does that solve the issue?
> 
> Unfortunately, getting rid of the [] around the echo statements
> doesn't solve it.  Autoconf still complains as before, and then the
> configure script fails with:
> 
> checking for SDL_IMAGE... ../configure: line 8532: syntax error near
> unexpected token `('

Okay, here's a second guess:

----------------------------------------------------------------------------
PKG_CHECK_MODULES([SDL_MIXER],
   [SDL_mixer],
   ,
   [
     [echo "SDL_MIXER not found via pkg_config, checking with AC_CHECK_LIB:"]
     [AC_CHECK_LIB([SDL_mixer],
        [Mix_OpenAudio],
        ,
        [AC_MSG_ERROR([SDL_mixer not found!
http://www.libsdl.org/projects/SDL_mixer])]
     )]
     [echo "SDL_MIXER successfully located"]
   ]
)
----------------------------------------------------------------------------

And here's a third one:

----------------------------------------------------------------------------
PKG_CHECK_MODULES([SDL_MIXER],
   [SDL_mixer],
   ,
     [echo "SDL_MIXER not found via pkg_config, checking with AC_CHECK_LIB:"]
     [AC_CHECK_LIB([SDL_mixer],
        [Mix_OpenAudio],
        ,
        [AC_MSG_ERROR([SDL_mixer not found!
http://www.libsdl.org/projects/SDL_mixer])]
     )]
     [echo "SDL_MIXER successfully located"]
)
----------------------------------------------------------------------------

> Although the current code seems to work (after a second autoreconf),
> these error messages worry me.  What's more, even by deleting the echo
> statements entirely, I can't seem to get back to a state that doesn't
> generate these errors.

Indeed, that's really strange.

BTW, a look into the M4 manpages or the Autoconf manpages might help.

Maybe some other quoting or a ";" or similar is needed, or maybe
there is a macro similar to "MSG_WARN" that is a proper replacement
for the "echo" statement.


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR

Re: [Tuxmath-devel] [Tux4kids-tuxtype-dev] No one on tuxtype this summer?

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

Hi Matt et al,

On Fri, Jun 11, 2010 at 7:23 PM, Matthew Trey <mt...@tr...> wrote:
> No one is on tuxtype this summer?

Well, we don't have any tuxtype-specific GSoC projects this summer,
but really all three of the tuxmath/tuxtype projects are aimed at both
of the programs.  One is for tux4kids-admin, one is aimed at improving
our use of SVG, and the third is aimed at getting the shared code
organized into a proper library.  Admittedly, all three have targeted
tuxmath first, with tuxtype to follow, but tuxtype really should see
some significant improvements from these projects.

David

p.s. - one tuxtype-specific issue that I really would like to see
fixed is that of input methods for Asian languages (or more generally,
for languages that use sequences of keypresses for a single
character).  Tuxpaint's input methods code (courtesy of Mark Kim) has
been merged into tuxtype, but it isn't actually used by the program
yet.  Until then, tuxtype can't support Chinese, Japanese, or Korean
(and likely other related languages as well).  We can display these
languages fine, but keyboard input doesn't currently work, AFAICT.

Re: [Tuxmath-devel] Including libxml2-devel library

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

Hi Volker,

> Just a quick guess, without having tested it:
>
> I'm not sure why you have to put the "echo" commands into separate
> parentheses. AFAIR that isn't necessary, and indeed an overquoting.
> So I propose to replace this:
>
>> PKG_CHECK_MODULES([SDL_MIXER],
>>     [SDL_mixer],
>>     ,
>>     [
>>       [echo "SDL_MIXER not found via pkg_config, checking with AC_CHECK_LIB:"]
>>       AC_CHECK_LIB([SDL_mixer],
>>          [Mix_OpenAudio],
>>          ,
>>          [AC_MSG_ERROR([SDL_mixer not found!
>> http://www.libsdl.org/projects/SDL_mixer])]
>>       )
>>       [echo "SDL_MIXER successfully located"]
>>     ]
>> )
>
> ... with that:
>
> ----------------------------------------------------------------------------
> PKG_CHECK_MODULES([SDL_MIXER],
>    [SDL_mixer],
>    ,
>    [
>      echo "SDL_MIXER not found via pkg_config, checking with AC_CHECK_LIB:"
>      AC_CHECK_LIB([SDL_mixer],
>         [Mix_OpenAudio],
>         ,
>         [AC_MSG_ERROR([SDL_mixer not found!
> http://www.libsdl.org/projects/SDL_mixer])]
>      )
>      echo "SDL_MIXER successfully located"
>    ]
> )
> ----------------------------------------------------------------------------
>
> Does that solve the issue?

Unfortunately, getting rid of the [] around the echo statements
doesn't solve it.  Autoconf still complains as before, and then the
configure script fails with:

checking for SDL_IMAGE... ../configure: line 8532: syntax error near
unexpected token `('

Although the current code seems to work (after a second autoreconf),
these error messages worry me.  What's more, even by deleting the echo
statements entirely, I can't seem to get back to a state that doesn't
generate these errors.  Anyway, thanks.

David Bruce

Re: [Tuxmath-devel] Including libxml2-devel library

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

David Bruce <dav...@gm...> schrieb:
> (Note: One slight problem I have had since going to this two-step
> check relates to the echo statements.  Without these statements, the
> output from configure is confusing because it show the PKG_CHECK_LIB
> step failing, then the AC_CHECK_LIB step succeeding, without a very
> clear indication that it is a fallback check.  With the echo
> statements, I had to put in another set of [] brackets, which causes
> autoconf to complain/fail on the first attempt (apparently from
> overquoting), but it succeeds and apparently works properly if run a
> second time.  If anyone has a good fix for this, I would be most
> appreciative).

Just a quick guess, without having tested it:

I'm not sure why you have to put the "echo" commands into separate
parentheses. AFAIR that isn't necessary, and indeed an overquoting.
So I propose to replace this:

> PKG_CHECK_MODULES([SDL_MIXER],
>     [SDL_mixer],
>     ,
>     [
>       [echo "SDL_MIXER not found via pkg_config, checking with AC_CHECK_LIB:"]
>       AC_CHECK_LIB([SDL_mixer],
>          [Mix_OpenAudio],
>          ,
>          [AC_MSG_ERROR([SDL_mixer not found!
> http://www.libsdl.org/projects/SDL_mixer])]
>       )
>       [echo "SDL_MIXER successfully located"]
>     ]
> )

... with that:

----------------------------------------------------------------------------
PKG_CHECK_MODULES([SDL_MIXER],
    [SDL_mixer],
    ,
    [
      echo "SDL_MIXER not found via pkg_config, checking with AC_CHECK_LIB:"
      AC_CHECK_LIB([SDL_mixer],
         [Mix_OpenAudio],
         ,
         [AC_MSG_ERROR([SDL_mixer not found!
http://www.libsdl.org/projects/SDL_mixer])]
      )
      echo "SDL_MIXER successfully located"
    ]
)
----------------------------------------------------------------------------

Does that solve the issue?


Greets,
Volker

-- 
Volker Grabsch
---<<(())>>---
Administrator
NotJustHosting GbR

Re: [Tuxmath-devel] Including libxml2-devel library

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

Hi Vikas,

>>> I am getting error on compilation of tuxmath. How to link the library
>>> libxml2-devel with makefile.am (if I am right)?
>>
>> I believe this is (or should be) done in configure.ac, not Makefile.am .

That's correct - configure.ac is how you determine what gets checked
when you run ./configure, which is when our package checks to see if
it the needed libs are available and sets the compilation flags.

As part of getting the mingw-cross-env crossbuild working, I recently
revised tuxmath's configure.ac fairly heavily with a lot of help from
Volker, mingw-cross-env's maintainer.  Basically, the simple way to
check for a library with autoconf is with AC_CHECK_LIB.  However, that
isn't sufficient for making a completely statically-linked program
like mingw-cross-env does, because all of the secondary dependencies
must be known at compile time.  If possible, pkg-config's
PKG_CHECK_MODULES is a more reliable way to make sure all the
dependencies are correctly linked.  However, pkg-config isn't
supported for all libraries on all systems.  Thus, we now use a
two-tier approach - attempt to find the lib first with
PKG_CHECK_MODULES, then fall back to AC_CHECK_LIB if needed.

Below is how this approach is used for SDL_mixer.  We should be able
to adapt this by substituting "libxml-2.0" for "SDL_mixer", "XML" for
"SDL_MIXER", etc.

(Note: One slight problem I have had since going to this two-step
check relates to the echo statements.  Without these statements, the
output from configure is confusing because it show the PKG_CHECK_LIB
step failing, then the AC_CHECK_LIB step succeeding, without a very
clear indication that it is a fallback check.  With the echo
statements, I had to put in another set of [] brackets, which causes
autoconf to complain/fail on the first attempt (apparently from
overquoting), but it succeeds and apparently works properly if run a
second time.  If anyone has a good fix for this, I would be most
appreciative).

Regards,

David Bruce


Excerpt from tuxmath's configure.ac: -----------------------------



dnl Check for SDL_mixer:
--------------------------------------------------------

PKG_CHECK_MODULES([SDL_MIXER],
    [SDL_mixer],
    ,
    [
      [echo "SDL_MIXER not found via pkg_config, checking with AC_CHECK_LIB:"]
      AC_CHECK_LIB([SDL_mixer],
	 [Mix_OpenAudio],
         ,
         [AC_MSG_ERROR([SDL_mixer not found!
http://www.libsdl.org/projects/SDL_mixer])]
      )
      [echo "SDL_MIXER successfully located"]
    ]
)

AC_DEFINE([HAVE_LIBSDL_MIXER],[1],[Define to 1 if you have the
`SDL_mixer` library])
CFLAGS="$CFLAGS $SDL_MIXER_CFLAGS"
LIBS="$LIBS $SDL_MIXER_LIBS"

Re: [Tuxmath-devel] Including libxml2-devel library

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

By the way, I can't remember whether I've shared this, but the guide
here might be helpful to you: http://fsmsh.com/2753

-Brendan

On Sat, Jun 12, 2010 at 7:28 PM, Brendan Luchen <bm...@ri...> wrote:
> Hey Vikas,
>
>> I am getting error on compilation of tuxmath.How to link the library
>> libxml2-devel with makefile.am (if I am right)?
>
> I believe this is (or should be) done in configure.ac, not Makefile.am .
>

Re: [Tuxmath-devel] Including libxml2-devel library

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

Hey Vikas,

> I am getting error on compilation of tuxmath.How to link the library
> libxml2-devel with makefile.am (if I am right)?

I believe this is (or should be) done in configure.ac, not Makefile.am .

Re: [Tuxmath-devel] Including libxml2-devel library

[Vikas S. <vik...@gm...>]

With reference to my above mail,
The header files in parse_xmlLesson.c are

#include "parse_xmlLesson.h"
#include <stdlib.h>
#include <gtk/gtk.h>
#include <libxml/xmlmemory.h>
#include <libxml/parser.h>
#include <libxml/tree.h>

I am getting error on compilation of tuxmath.How to link the library
libxml2-devel with makefile.am (if I am right)?



-- 

Vikas Singh

Re: [Tuxmath-devel] Prerendered PNG cache for SVG sprites

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

Hmm...I see. That makes sense. Give me a bit of time to fix up that one!

Wenyuan

On Sat, Jun 12, 2010 at 2:56 AM, David Bruce <dav...@gm...> wrote:
> Hi Wenyuan,
>
> On Fri, Jun 11, 2010 at 7:52 AM, Tim Holy <ho...@wu...> wrote:
>> Hi Wenyuan,
>>
>> On Thursday, June 10, 2010 11:41:45 pm Wenyuan Guo wrote:
>>> Do you have write access to your tuxmath install directory (in my
>>> case, /usr/local/share/tuxmath) and whether there is enough disk
>>> space? The caching PNG files will be written to the same directories
>>> where the original SVG sprites are located.
>>
>> On Linux systems, the typical default (e.g., for distributor-supplied
>> packages, or a default make install) is to have the SVGs in some system
>> directory, to which users do not have write access.
>
> I agree - the PNG cache can't be located under the install directory,
> because that will not be writeable by ordinary users.  This situation
> has a lot in common with the "custom word list" tuxtype project from
> last summer - ideally, we might want to have an area that is writeable
> by tuxmath and readable by all users.  Our high score table has
> similar considerations. I found out that this is a thorny problem for
> distro packagers - if they are into security, they won't allow any
> files that are user-writeable outside of /home.  The traditional way
> to handle this is to make the file setgid for games, and put tuxtype
> into the games group.  Some distros (e.g. Fedora) didn't even like
> that idea, and said we ought to write a dedicated daemon to handle
> such file operations.  At that point, I gave up for the time being.
>
> For this case, I think we should just put the cache under ~/.tuxmath.
> If tuxmath subsequently gets run by another user, nothing bad will
> happen except for the slower startup the first time while the
> rescaling takes place.
>
> Cheers,
>
> David Bruce
>
> ------------------------------------------------------------------------------
> ThinkGeek and WIRED's GeekDad team up for the Ultimate
> GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
> lucky parental unit.  See the prize list and enter to win:
> http://p.sf.net/sfu/thinkgeek-promo
> _______________________________________________
> Tuxmath-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxmath-devel
>

Re: [Tuxmath-devel] Prerendered PNG cache for SVG sprites

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

Hi Wenyuan,

On Fri, Jun 11, 2010 at 7:52 AM, Tim Holy <ho...@wu...> wrote:
> Hi Wenyuan,
>
> On Thursday, June 10, 2010 11:41:45 pm Wenyuan Guo wrote:
>> Do you have write access to your tuxmath install directory (in my
>> case, /usr/local/share/tuxmath) and whether there is enough disk
>> space? The caching PNG files will be written to the same directories
>> where the original SVG sprites are located.
>
> On Linux systems, the typical default (e.g., for distributor-supplied
> packages, or a default make install) is to have the SVGs in some system
> directory, to which users do not have write access.

I agree - the PNG cache can't be located under the install directory,
because that will not be writeable by ordinary users.  This situation
has a lot in common with the "custom word list" tuxtype project from
last summer - ideally, we might want to have an area that is writeable
by tuxmath and readable by all users.  Our high score table has
similar considerations. I found out that this is a thorny problem for
distro packagers - if they are into security, they won't allow any
files that are user-writeable outside of /home.  The traditional way
to handle this is to make the file setgid for games, and put tuxtype
into the games group.  Some distros (e.g. Fedora) didn't even like
that idea, and said we ought to write a dedicated daemon to handle
such file operations.  At that point, I gave up for the time being.

For this case, I think we should just put the cache under ~/.tuxmath.
If tuxmath subsequently gets run by another user, nothing bad will
happen except for the slower startup the first time while the
rescaling takes place.

Cheers,

David Bruce

Re: [Tuxmath-devel] Prerendered PNG cache for SVG sprites

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

Hi Wenyuan,

On Thursday, June 10, 2010 11:41:45 pm Wenyuan Guo wrote:
> Do you have write access to your tuxmath install directory (in my
> case, /usr/local/share/tuxmath) and whether there is enough disk
> space? The caching PNG files will be written to the same directories
> where the original SVG sprites are located.

On Linux systems, the typical default (e.g., for distributor-supplied 
packages, or a default make install) is to have the SVGs in some system 
directory, to which users do not have write access.

Perhaps there should be a fallback in which the user's own .tuxmath directory 
is used for the cached PNGs? In a subdirectory named "cached" or somesuch?

> > @Tim: Wow! Wherever you are, it sounds fun. I guess, welcome to the
> > mile-high club of free software (?)

Colorado. They typically hold scientific meetings in fun places, and we are 
sneaking a family vacation in afterwards.

Best,
--Tim