tuxnes-devel — Development discussion for the TuxNES project

[Tuxnes-devel] CVS commit log for Tuxnes

[Mike M. <ch...@us...>]

Update of /cvsroot/tuxnes/tuxnes
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv18978

Modified Files:
	Makefile.am 
Log Message:
This patch changes tuxnes_SOURCES to include all the sources for tuxnes. 
  This allows "make dist" to generate a tarball that includes all the 
  files.  Yay!
  "Jason Dorje Short"

[Tuxnes-devel] compile without gettimeofday

[Jason D. S. <jd...@us...>]

gettimeofday() is not present on all systems.  (One such system is win32.)

When it's not present we should be able to use ftime().  This is an 
obsolete POSIX function.  (It doesn't matter that it's obsolete, since 
we're doing a configure check for it.)

This patch makes the change.  After the change we can no longer use the 
timeval struct; we have to track seconds and useconds manually.  It 
would probably be quite a bit easier to do this in one variable by 
tracking the seconds as a double.  This may not be perfectly accurate, 
but is probably more accurate than what we do now (which is itself very 
accurate).

jason

[Tuxnes-devel] "make distcheck" doesn't work

[Jason D. S. <jd...@us...>]

"make dist" makes a tarball.  ("make distcheck" makes the tarball and 
then compiles it to test it.)  But the tarball won't compile because not 
all the sources are included in it.  (Header files have to be included 
in the list.  Although they're not compiled, there's no other way for 
automake to know to include them in the distribution.)

This patch changes tuxnes_SOURCES to include all the sources for tuxnes. 
  This allows "make dist" to generate a tarball that includes all the 
files.  Yay!

(I got the list of sources by removing all *.[ch] files, then doing a 
cvs update, then doing "ls *.[ch]".  I removed comptbl.c from this list, 
and added emulator_x86_asm.S back in.  The list is sorted alphabetically 
and formated nicely.)


This doesn't fix everything, however.  There are still problems with 
emulator_x86_asm.S:

- When compiling it gcc doesn't get all the normal CFLAGS.  This means 
that there is no -I$(top_builddir) parameter so when the builddir isn't 
the same as the sourcedir inclusion of config.h will fail.  (If that 
didn't make any sense, try "make distcheck" and watch it fail.  Or try 
"make distclean && mkdir build && cd build && ../configure && make" in 
the top-level source directory.  This isn't ever used by a typical user, 
but is often used to build binary packages because the developer can 
build multiple packages out of the same source directory.)

- emulator_x86_asm.S is always compiled.  I imagine this means 
compilation will fail on any non-x86 system.

These are unrelated to "make dist", of course.

jason

[Tuxnes-devel] io.h

[Jason D. S. <jd...@us...>]

The existance of io.h presents a problem when cross-compiling.  io.h is 
a needed header, and for some reason when the other headers #include 
<io.h> it actually includes the local copy.  Hence, compilation fails.

I'd suggest renaming io.h to nesio.h.  Maybe io.c should be renamed to 
match.

jason

Re: [Tuxnes-devel] tuxnes and efp (fwd)

[Mike M. <che...@ya...>]

Yes, translate is part of the x86 core.  You must be running 0.75 or
older.    I'l test with the latesed code.

Try this patch from CVS.
http://cvs.sourceforge.net/viewcvs.py/tuxnes/tuxnes/Attic/dynrec.c?r1=1.9&r2=1.10&sortby=date&diff_format=u

===================================================================
RCS file: /cvsroot/tuxnes/tuxnes/Attic/dynrec.c,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- tuxnes/tuxnes/Attic/dynrec.c	2001/04/11 21:45:47	1.9
+++ tuxnes/tuxnes/Attic/dynrec.c	2001/05/02 23:55:20	1.10
@@ -4,7 +4,7 @@
  * Please see the README and COPYING files for more information regarding
  * this project.
  *
- * $Id: dynrec.c,v 1.9 2001/04/11 21:45:47 tmmm Exp $
+ * $Id: dynrec.c,v 1.10 2001/05/02 23:55:20 pez3 Exp $
  *
  * Description: This is the dynamic recompiler.  This takes 6502 code as
  * input, looks up the opcodes in the translation dictionary, evaluates
@@ -96,21 +96,27 @@
               l = *(sptr++);
               o = *(sptr++);
               /*printf("[%c%d %d]",m,o,l);fflush(stdout); */
-              if (m == '!')
-                stop = 1;
-              if (m == 'B')
-                bptr[l] = *(MAPTABLE[(saddr + o) >> 12] + (saddr + o));
-              if (m == 'C')
-                bptr[l] = ~*(MAPTABLE[(saddr + o) >> 12] + (saddr + o));
-              if (m == 'D')
-                *((unsigned int *) (bptr + l)) = (unsigned int) bptr + l
+ o;
-              if (m == 'E')
-                *((int *) (bptr + l)) = *((signed char *)
(MAPTABLE[(saddr +
+              switch(m) {
+                case '!':
+                  stop = 1;
+                  break;
+                case 'B':
+                  bptr[l] = *(MAPTABLE[(saddr + o) >> 12] + (saddr + o));
+                  break;
+                case 'C':
+                  bptr[l] = ~*(MAPTABLE[(saddr + o) >> 12] + (saddr +
o));
+                  break;
+                case 'D':
+                  *((unsigned int *) (bptr + l)) = (unsigned int) bptr +
l + o;
+                  break;
+                case 'E':
+                  *((int *) (bptr + l)) = *((signed char *)
(MAPTABLE[(saddr +
                                                                      o)
>>
                                                         12] + (saddr +
o)));
-              if (m == 'Z')
-                *((unsigned int *) (bptr + l)) = (unsigned int) ZPMEM +
-                  *(MAPTABLE[(saddr
+                  break;
+                case 'Z':
+                  *((unsigned int *) (bptr + l)) = (unsigned int) ZPMEM +
+                    *(MAPTABLE[(saddr
                               +
                               o)
                              >>
@@ -118,9 +124,10 @@
                     +
                     saddr
                     + o);
-              if (m == 'A')
-                *((unsigned int *) (bptr + l)) = (unsigned int) RAM +
-                  *(MAPTABLE[(saddr
+                  break;
+                case 'A':
+                  *((unsigned int *) (bptr + l)) = (unsigned int) RAM +
+                    *(MAPTABLE[(saddr
                               +
                               o)
                              >>
@@ -129,12 +136,14 @@
                     saddr
                     + o)
                   + ((*(MAPTABLE[(saddr + o + 1) >> 12] + saddr + o + 1))
<< 8);
-              if (m == 'L')
-                *((unsigned int *) (bptr + l)) = (unsigned int) RAM;
-              if (m == 'W')
-                *((unsigned short *) (bptr + l)) = *(MAPTABLE[(saddr + o)
>>
+                  break;
+                case 'L':
+                  *((unsigned int *) (bptr + l)) = (unsigned int) RAM;
+                  break;
+                case 'W':
+                  *((unsigned short *) (bptr + l)) = *(MAPTABLE[(saddr +
o) >>
                                                           12] + saddr +
o) +
-                  ((*(MAPTABLE[(saddr
+                    ((*(MAPTABLE[(saddr
                                 +
                                 o
                                 +
@@ -147,9 +156,10 @@
                       o
                       +
                       1))
-                   << 8);
-              if (m == 'X')
-                *((unsigned int *) (bptr + l)) = (unsigned int) (MAPTABLE
+
+                     << 8);
+                  break;
+                case 'X':
+                  *((unsigned int *) (bptr + l)) = (unsigned int)
(MAPTABLE +
                                                         
((*(MAPTABLE[(saddr
                                                                        +
                                                                        o
@@ -164,21 +174,26 @@
                                                              +
                                                              1))
                                                           >> 4));
-              if (m == 'M')
-                *((unsigned int *) (bptr + l)) = (unsigned int)
(MAPTABLE);
-              if (m == 'T')
-                *((unsigned int *) (bptr + l)) = (unsigned int) STACK;
-              if (m == 'P')
-                *((unsigned short *) (bptr + l)) = saddr + o;
-              if (m == 'R')
-                *((int *) (bptr + l)) = *((signed char *)
(MAPTABLE[(saddr +
+                  break;
+                case 'M':
+                  *((unsigned int *) (bptr + l)) = (unsigned int)
(MAPTABLE);
+                  break;
+                case 'T':
+                  *((unsigned int *) (bptr + l)) = (unsigned int) STACK;
+                  break;
+                case 'P':
+                  *((unsigned short *) (bptr + l)) = saddr + o;
+                  break;
+                case 'R':
+                  *((int *) (bptr + l)) = *((signed char *)
(MAPTABLE[(saddr +
                                                                      o)
>>
                                                            12] + saddr +
o))
-                  + saddr + o + 1;
-              if (m == 'J')
-                *((unsigned int *) (bptr + l)) = *(MAPTABLE[(saddr + o)
>>
+                    + saddr + o + 1;
+                  break;
+                case 'J':
+                  *((unsigned int *) (bptr + l)) = *(MAPTABLE[(saddr + o)
>>
                                                           12] + saddr +
o) +
-                  ((*(MAPTABLE[(saddr
+                    ((*(MAPTABLE[(saddr
                                 +
                                 o
                                 +
@@ -190,32 +205,45 @@
                       + o
                       +
                       1))
-                   << 8);
-              if (m == 'S')
-                *((void **) (bptr + l)) = &STACKPTR;
-              if (m == 'V')
-                *((void **) (bptr + l)) = &VFLAG;
-              if (m == 'F')
-                *((void **) (bptr + l)) = &FLAGS;
-              if (m == 'I')
-                *((int *) (bptr + l)) = (int) (&INPUT) - (int) (bptr + l)
- 4;
-              if (m == 'O')
-                *((int *) (bptr + l)) = (int) (&OUTPUT) - (int) (bptr +
l) - 4;
-              if (m == 'U')
-                *((int *) (bptr + l)) = (int) (&U) - (int) (bptr + l) -
4;
-              if (m == 'N')
-                *((int *) (bptr + l)) = (int) (&NMI) - (int) (bptr + l) -
4;
-              if (m == 'Y')
-                *((int *) (bptr + l)) = (int) (Mapper[MAPPERNUMBER]) -
(int)
-                  (bptr
-                   +
-                   l) - 4;
-              if (m == '>')
-                bptr[l] += (((*((signed char *) (MAPTABLE[(saddr + o) >>
12]
+                     << 8);
+                  break;
+                case 'S':
+                  *((void **) (bptr + l)) = &STACKPTR;
+                  break;
+                case 'V':
+                  *((void **) (bptr + l)) = &VFLAG;
+                  break;
+                case 'F':
+                  *((void **) (bptr + l)) = &FLAGS;
+                  break;
+                case 'I':
+                  *((int *) (bptr + l)) = (int) (&INPUT) - (int) (bptr +
l) - 4;
+                  break;
+                case 'O':
+                  *((int *) (bptr + l)) = (int) (&OUTPUT) - (int) (bptr +
l) 
+                      - 4;
+                  break;
+                case 'U':
+                  *((int *) (bptr + l)) = (int) (&U) - (int) (bptr + l) -
4;
+                  break;
+                case 'N':
+                  *((int *) (bptr + l)) = (int) (&NMI) - (int) (bptr + l)
- 4;
+                  break;
+                case 'Y':
+                  *((int *) (bptr + l)) = (int) (Mapper[MAPPERNUMBER]) -
(int)
+                    (bptr
+                     +
+                     l) - 4;
+                  break;
+                case '>':
+                  bptr[l] += (((*((signed char *) (MAPTABLE[(saddr + o)
>> 12]
                                                  + saddr + o)) + saddr +
o +
                               1) & 0xFF00) != ((saddr + o + 1) &
0xFF00));
-	      if (m == '^')
-		bptr[l] = ignorebadinstr ? NOP : BRK;
+                  break;
+                case '^':
+                  bptr[l] = ignorebadinstr ? NOP : BRK;
+                  break;
+              }
             }
           addr = saddr + slen;
         }


--- Mike Melanson <mel...@pc...> wrote:
> Info on a free ROM (that fails to work with TuxNES).
> 
> --
> 	-Mike Melanson
> 
> ---------- Forwarded message ----------
> Date: Tue, 24 Feb 2004 16:34:51 -0500
> From: Joey Hess <jo...@ki...>
> To: Mike Melanson <mel...@pc...>
> Subject: tuxnes and efp
> 
> efp is a free ROM available from http://hcs.freeshell.org/efp.html
> Tuxnes segfaults on startup with this rom. Here is a backtrace of the
> child process it forks, which is the one that segfaults:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0804b9ec in translate (addr=32768) at dynrec.c:65
> 65            INT_MAP[(MAPTABLE[addr >> 12] + addr) - RAM] = (unsigned
> int) cptr;
> (gdb) bt
> #0  0x0804b9ec in translate (addr=32768) at dynrec.c:65
> #1  0x0804f746 in main (argc=3, argv=0xbffff894) at emu.c:2216
> (gdb) p addr
> $1 = 32768
> (gdb) p cptr
> $2 = (unsigned char *) 0x12000000 ""
> 
> -- 
> see shy jo
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Tuxnes-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxnes-devel


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

[Tuxnes-devel] tuxnes and efp (fwd)

[Mike M. <mel...@pc...>]

Info on a free ROM (that fails to work with TuxNES).

--
	-Mike Melanson

---------- Forwarded message ----------
Date: Tue, 24 Feb 2004 16:34:51 -0500
From: Joey Hess <jo...@ki...>
To: Mike Melanson <mel...@pc...>
Subject: tuxnes and efp

efp is a free ROM available from http://hcs.freeshell.org/efp.html
Tuxnes segfaults on startup with this rom. Here is a backtrace of the
child process it forks, which is the one that segfaults:

Program received signal SIGSEGV, Segmentation fault.
0x0804b9ec in translate (addr=32768) at dynrec.c:65
65            INT_MAP[(MAPTABLE[addr >> 12] + addr) - RAM] = (unsigned int) cptr;
(gdb) bt
#0  0x0804b9ec in translate (addr=32768) at dynrec.c:65
#1  0x0804f746 in main (argc=3, argv=0xbffff894) at emu.c:2216
(gdb) p addr
$1 = 32768
(gdb) p cptr
$2 = (unsigned char *) 0x12000000 ""

-- 
see shy jo

[Tuxnes-devel] CVS commit log for Tuxnes

[Mike M. <ch...@us...>]

Update of /cvsroot/tuxnes/tuxnes
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv27583

Modified Files:
	emu.c emulator.c emulator.h emulator_c_iface.c emulator_x86.c 
	emulator_x86.h emulator_x86_asm.S emulator_x86_dynrec.c 
	globals.h mapper.c 
Log Message:
A days work on x86 core.  includes lots of small changes, renaming, and
white space.  expected to break things, but nothing obvious.  x86 core does
not crash or work, now.

[Tuxnes-devel] CVS commit log for Tuxnes

[Mike M. <ch...@us...>]

Update of /cvsroot/tuxnes/tuxnes
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv22717

Modified Files:
	controller.c renderer_x11.c 
Log Message:
HAVE_X_LIBS -> HAVE_X, and removed useless fork.

Re: [Tuxnes-devel] x11 renderer in current cvs heads up.

[Mike M. <che...@ya...>]

Good, what's the date on the last commit you have?

---

Nestra workes fine for me and I am using it as a referance for the x86
core(emulator).  It lookes like the nestra code I'm bringing over was once
part of tuxnes, but it got ripped ought when c based emulation was added.

--- Jason Dorje Short <jd...@us...> wrote:
> Mike Mestnik wrote:
> > On my system -r x11 dose not respond to input and has frame skip.  SDL
> > workes fine thought.  This is from latesed devel CVS, may not have hit
> > anaocvs yet.  I will look into what I broke latter today.
> > 
> > I'm hoping otheres can verify this behaviour so I can commit my -C x86
> > fixups and get that enabeled per default.
> 
> I see this as well, though I think I don't have your latest commit yet.
> 
> ---
> 
> I took a look at Nestra.  It hasn't been updated since 1999 and it 
> crashes when I try to run it.  So I don't know what to make of it.  It 
> is in the public domain, though, so features from it could be merged 
> safely into tuxnes.  It's quite small, though, so I doubt it has much 
> that tuxnes doesn't.
> 
> jason
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

Re: [Tuxnes-devel] x11 renderer in current cvs heads up.

[Jason D. S. <jd...@us...>]

Mike Mestnik wrote:
> On my system -r x11 dose not respond to input and has frame skip.  SDL
> workes fine thought.  This is from latesed devel CVS, may not have hit
> anaocvs yet.  I will look into what I broke latter today.
> 
> I'm hoping otheres can verify this behaviour so I can commit my -C x86
> fixups and get that enabeled per default.

I see this as well, though I think I don't have your latest commit yet.

---

I took a look at Nestra.  It hasn't been updated since 1999 and it 
crashes when I try to run it.  So I don't know what to make of it.  It 
is in the public domain, though, so features from it could be merged 
safely into tuxnes.  It's quite small, though, so I doubt it has much 
that tuxnes doesn't.

jason

[Tuxnes-devel] x11 renderer in current cvs heads up.

[Mike M. <che...@ya...>]

On my system -r x11 dose not respond to input and has frame skip.  SDL
workes fine thought.  This is from latesed devel CVS, may not have hit
anaocvs yet.  I will look into what I broke latter today.

I'm hoping otheres can verify this behaviour so I can commit my -C x86
fixups and get that enabeled per default.


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

[Tuxnes-devel] CVS commit log for Tuxnes

[Mike M. <ch...@us...>]

Update of /cvsroot/tuxnes/tuxnes
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv13066

Modified Files:
	defines.h globals.h io.c 
Log Message:
Removed VRAM vram define and users.

[Tuxnes-devel] CVS commit log for Tuxnes

[Mike M. <ch...@us...>]

Update of /cvsroot/tuxnes/tuxnes
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv24224

Modified Files:
	configure.ac controller.c 
Log Message:
AC_CHECK_TYPES can't span multiple lines, fixed: Jason Dorje Short

[Tuxnes-devel] stdint patch broke compilation

[Jason D. S. <jd...@us...>]

Looks like putting AC_CHECK_TYPES on multiple lines (which I did at the 
very end) breaks it.  The current behavior gives a

#define HAVE______UINT32_T

in config.h, which means uint32_t is redefined in types.h, which breaks.

This patch puts it all on one line, with a comment.

jason

Re: [Tuxnes-devel] autoconf checks for integer types

[Jeroen Ruigrok/a. <as...@wx...>]

-On [20040220 03:52], Jason Dorje Short (jd...@us...) wrote:
>It may be overkill to check them all individually.  Whatever.

>-AC_CHECK_TYPES([suseconds_t])
>+AC_CHECK_TYPES([suseconds_t, int8_t, int16_t, int32_t, uint8_t, uint16_t, \
>+		uint32_t])

If the platform is POSIX compliant these should be supported.

-- 
Jeroen Ruigrok van der Werven <asmodai(at)wxs.nl> / asmodai / kita no mono
PGP fingerprint: 2D92 980E 45FE 2C28 9DB7  9D88 97E6 839B 2EAC 625B
http://www.tendra.org/   | http://diary.in-nomine.org/
I believe because it is impossible...

[Tuxnes-devel] CVS commit log for Tuxnes

[Mike M. <ch...@us...>]

Update of /cvsroot/tuxnes/tuxnes
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3841

Modified Files:
	configure.ac emulator_c.h emulator_c_iface.h types.h 
Log Message:
Autoconf checks for integer types: Jason Dorje Short

[Tuxnes-devel] autoconf checks for integer types

[Jason D. S. <jd...@us...>]

This patch does autconf checks for the integer types (uint8_t, etc.).

It may be overkill to check them all individually.  Whatever.

jason

[Tuxnes-devel] CVS commit log for Tuxnes

[Mike M. <ch...@us...>]

Update of /cvsroot/tuxnes/tuxnes
In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv32041

Modified Files:
	renderer.c 
Log Message:
Segfaulting renderers fixed.

Re: [Tuxnes-devel] renderer.c compile problem

[Mike M. <che...@ya...>]

Good catch, these structs are one member short.  I.E. 0 _flags is the
integer, char* controlname is the cast.

--- Jason Dorje Short <jd...@us...> wrote:
> renderer.c:75: warning: initialization makes integer from pointer 
> without a castrenderer.c:78: warning: initialization makes integer from 
> pointer without a castrenderer.c:78: warning: initialization from 
> incompatible pointer type
> 
> They're just warnings, but pretty severe.  A new field was added to the 
> struct but these entries didn't get it.
> 
> I use
> 
>    alias make="make CFLAGS=\"-g -Wall -Werror -Wcast-align 
> -Wmissing-prototypes -Wmissing-declarations\""
> 
> which catches problems like this (as well as preventing compilation in a
> 
> lot of projects that have many warnings; I use "unalias make" a lot).
> 
> jason
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Tuxnes-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxnes-devel


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

Re: [Tuxnes-devel] tuxnes CVS mailings

[Mike M. <che...@ya...>]

I have seen this being used.  I guess it's kindof usefull, Thought I would
like patches to be generated and sent to a tuxnes-patches list.  I guess
it's just cause I don't know why it would be use full to know that <user>
made a commit and this <time>?

--- Jason Dorje Short <jd...@us...> wrote:
> It's possible to set up CVS so that it sends mail to a list on every
> commit.
> 
> Checkout the CVSROOT module, apply this patch, and create the tuxnes-cvs
> 
> mailing list.  (Or test it with a local mailing first, if you like.)
> 
> Most other projects do this.  It is useful for monitoring development. 
> (Look at other CVSROOT modules for examples.)
> 
> jason
> > Index: loginfo
> ===================================================================
> RCS file: /cvsroot/tuxnes/CVSROOT/loginfo,v
> retrieving revision 1.1
> diff -u -r1.1 loginfo
> --- loginfo	31 Dec 2000 01:45:01 -0000	1.1
> +++ loginfo	19 Feb 2004 23:35:30 -0000
> @@ -24,3 +24,5 @@
>  #DEFAULT (echo ""; id; echo %s; date; cat) >>
> $CVSROOT/CVSROOT/commitlog
>  # or
>  #DEFAULT (echo ""; id; echo %{sVv}; date; cat) >>
> $CVSROOT/CVSROOT/commitlog
> +
> +DEFAULT mail -s "CVS commit log for Tuxnes"
> tux...@li...
> 


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools

[Tuxnes-devel] tuxnes CVS mailings

[Jason D. S. <jd...@us...>]

It's possible to set up CVS so that it sends mail to a list on every commit.

Checkout the CVSROOT module, apply this patch, and create the tuxnes-cvs 
mailing list.  (Or test it with a local mailing first, if you like.)

Most other projects do this.  It is useful for monitoring development. 
(Look at other CVSROOT modules for examples.)

jason

Re: [Tuxnes-devel] renderer.c compile problem

[Jason D. S. <jd...@us...>]

Jason Dorje Short wrote:
> renderer.c:75: warning: initialization makes integer from pointer 
> without a castrenderer.c:78: warning: initialization makes integer from 
> pointer without a castrenderer.c:78: warning: initialization from 
> incompatible pointer type
> 
> They're just warnings, but pretty severe.  A new field was added to the 
> struct but these entries didn't get it.
> 
> I use
> 
>   alias make="make CFLAGS=\"-g -Wall -Werror -Wcast-align 
> -Wmissing-prototypes -Wmissing-declarations\""
> 
> which catches problems like this (as well as preventing compilation in a 
> lot of projects that have many warnings; I use "unalias make" a lot).

- Naturally this causes a segfault.
- Looks like it effects the W renderer as well.

jason

[Tuxnes-devel] renderer.c compile problem

[Jason D. S. <jd...@us...>]

renderer.c:75: warning: initialization makes integer from pointer 
without a castrenderer.c:78: warning: initialization makes integer from 
pointer without a castrenderer.c:78: warning: initialization from 
incompatible pointer type

They're just warnings, but pretty severe.  A new field was added to the 
struct but these entries didn't get it.

I use

   alias make="make CFLAGS=\"-g -Wall -Werror -Wcast-align 
-Wmissing-prototypes -Wmissing-declarations\""

which catches problems like this (as well as preventing compilation in a 
lot of projects that have many warnings; I use "unalias make" a lot).

jason

[Tuxnes-devel] inline cleanup

[Jason D. S. <jd...@us...>]

This patch uses AC_C_INLINE to check for inline.  I remove the 
definition and users of INLINE.

Inline may be defined to "inline", "__inline", or "" (for instance).  In 
all cases the code should be able to compile fine.  The inline keyword 
is just a hint to the compiler.  Since we compile with -O instead of 
(the default) -O2 or -O3 it's probably ignored anyway (I don't know).

Note that inline is already used elsewhere.  But non-static inlines 
generally won't be inlined. (At least the last time I checked.  gcc 
compiles foo.c into foo.o and bar.c into bar.o.  A function declared as 
inline in foo.c that is used in bar.c can't be inlined because the two 
pieces of code aren't compiled at the same time.  But if you put the 
function into foo.h or bar.c then it can be inlined.)  None of this 
really matters since inlining is surely not needed.  What's slow is the 
renderer, and this is all done in libraries.

jason

Re: [Tuxnes-devel] Re: NO LIST ARCHIVES?? for tuxnes-devel.

[Mike M. <che...@ya...>]

Ohh, OK it was just down then.  The list is working fine.

--- Jason Dorje Short <jd...@us...> wrote:
> Mike Mestnik wrote:
> > I could not find any arcives of the tuxnes-devel list!  Should I file
> a
> > sfbt issue or dose some one know why?
> 
> Hmm?  See
> 
>
http://sourceforge.net/mailarchive/forum.php?thread_id=3914383&forum_id=2494
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Tuxnes-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxnes-devel


__________________________________
Do you Yahoo!?
Yahoo! Mail SpamGuard - Read only the mail you want.
http://antispam.yahoo.com/tools