You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
(1) |
Mar
|
Apr
(3) |
May
(5) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
(6) |
| 2002 |
Jan
(11) |
Feb
|
Mar
(5) |
Apr
|
May
(1) |
Jun
(2) |
Jul
(3) |
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(1) |
| 2003 |
Jan
(1) |
Feb
(11) |
Mar
(33) |
Apr
(8) |
May
(10) |
Jun
(1) |
Jul
(1) |
Aug
(5) |
Sep
(4) |
Oct
(3) |
Nov
(6) |
Dec
(22) |
| 2004 |
Jan
(46) |
Feb
(16) |
Mar
(39) |
Apr
(29) |
May
(27) |
Jun
(11) |
Jul
(8) |
Aug
(15) |
Sep
(29) |
Oct
(12) |
Nov
(42) |
Dec
(19) |
| 2005 |
Jan
(2) |
Feb
(64) |
Mar
(87) |
Apr
(35) |
May
(6) |
Jun
(20) |
Jul
(34) |
Aug
(73) |
Sep
(39) |
Oct
(20) |
Nov
(3) |
Dec
(9) |
| 2006 |
Jan
(3) |
Feb
(17) |
Mar
(6) |
Apr
(6) |
May
(20) |
Jun
(18) |
Jul
|
Aug
(2) |
Sep
(4) |
Oct
(5) |
Nov
(13) |
Dec
(5) |
| 2007 |
Jan
|
Feb
(4) |
Mar
(17) |
Apr
(4) |
May
(4) |
Jun
(4) |
Jul
(1) |
Aug
(3) |
Sep
(13) |
Oct
(15) |
Nov
(21) |
Dec
(9) |
| 2008 |
Jan
(12) |
Feb
(9) |
Mar
(14) |
Apr
(35) |
May
(17) |
Jun
(23) |
Jul
(28) |
Aug
(34) |
Sep
(24) |
Oct
(9) |
Nov
(6) |
Dec
(4) |
| 2009 |
Jan
(27) |
Feb
(8) |
Mar
(5) |
Apr
(3) |
May
|
Jun
(4) |
Jul
(7) |
Aug
(13) |
Sep
(9) |
Oct
(5) |
Nov
|
Dec
|
| 2010 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
(3) |
May
(4) |
Jun
(4) |
Jul
(10) |
Aug
(7) |
Sep
(5) |
Oct
(4) |
Nov
(4) |
Dec
(1) |
| 2011 |
Jan
(3) |
Feb
(6) |
Mar
|
Apr
(2) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(5) |
| 2012 |
Jan
(5) |
Feb
(13) |
Mar
(6) |
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
(5) |
Nov
(9) |
Dec
(3) |
| 2013 |
Jan
|
Feb
(5) |
Mar
|
Apr
(4) |
May
|
Jun
(3) |
Jul
|
Aug
(1) |
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2014 |
Jan
(2) |
Feb
|
Mar
|
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
(1) |
Nov
(4) |
Dec
(2) |
| 2015 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
(2) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(4) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2023 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2024 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
| 2025 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(4) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| S | M | T | W | T | F | S |
|---|---|---|---|---|---|---|
|
1
(1) |
2
|
3
|
4
(1) |
5
|
6
|
7
|
|
8
|
9
(2) |
10
|
11
|
12
|
13
(1) |
14
|
|
15
|
16
|
17
|
18
|
19
|
20
|
21
|
|
22
|
23
|
24
|
25
|
26
|
27
|
28
|
|
29
|
30
|
31
|
|
|
|
|
|
From: Matteo L. <ma...@lu...> - 2009-03-13 20:04:10
|
Dear friends, I created a new open-source project "Network game torcs-ng" on Cofundos.org. You can view the complete project description at: http://www.cofundos.org/project.php?id=152 Since I assume the project could be of interest for you too I would like to invite you to comment and bid on the project. Thanks, |
|
From: Brent B. <bre...@gm...> - 2009-03-09 22:43:14
|
Found it. This may be a help to anyone else who is trying to build portable software. The issue is caused by the platform SDK one compiles against. The PLIB framework was built against the Leopard 10.5 SDK, and I was attempting to build everything against the 10.4 SDK. Sure enough, OpenGL/gl.h in 10.5 defines GLenum as "unsigned int", and the old 10.4 gl.h has "unsigned long". Unsigned int is the safer of the two going forward into 64bit apps, which is probably why it changed. Once I set everything to build against 10.5 SDK, the errors went away. I could have also rebuilt plib with 10.4. Libraries that do not link against anything beyond standard C/C++ libraries will not have this problem, but whenever any SDK framework is used (CoreImage, OpenAL, OpenGL, etc), the SDK choice is important. -Brent On Sun, Mar 8, 2009 at 9:36 PM, Brent Burton <bre...@gm...> wrote: > Some observations on the linkage issue with plib. > > The issue occurs with the ssggraph module, and the grVtxTable subclass > of plib's ssgVtxTable. One of the ssgVtxTable constructors is: > ssgVtxTable(GLenum type, ssgVertexArray* va, ssgNormalArray* na, > ssgTexCoordArray* ta, ssgColourArray* ca) > ... > [unsigned int vs unsigned long in link search] |
|
From: Brent B. <bre...@gm...> - 2009-03-09 02:36:18
|
Some observations on the linkage issue with plib.
The issue occurs with the ssggraph module, and the grVtxTable subclass
of plib's ssgVtxTable. One of the ssgVtxTable constructors is:
ssgVtxTable(GLenum type, ssgVertexArray* va, ssgNormalArray* na,
ssgTexCoordArray* ta, ssgColourArray* ca)
GLenum is defined as "unsigned int" in GL/gl.h, so the output from the
plib framework's dylib (or a local static lib) has the signature:
$ nm -g plib.framework/Versions/A/plib | c++filt | grep
'ssgVtxTable::ssgVtxTable'
00075972 T ssgVtxTable::ssgVtxTable(unsigned int, ...as above...)
0000234e T ssgVtxTable::ssgVtxTable(unsigned int, .....)
# <- output from my /usr/local/lib/libplibssg.a
I wrote a small test code based on the grVtxTable subclassing that
replicates this problem. The main() simply instantiates a grVtxTable,
which in turn invokes the above constructor. In tinkering with this
test, I found when it works and when it doesn't link.
If I compile the code manually, but link against *static* libraries,
the link works fine. The test source object file is looking for:
nm -g libvtx.o | c++filt | grep 'ssgVtxTable::ssgVtxTable'
U ssgVtxTable::ssgVtxTable(unsigned int, ...as above...)
and the linker finds it in the static libraries.
If I compile the test code to make a .so (as Torcs does), then the
compiler is attempting to find the signature with "unsigned long":
$ nm -g libvtx.o | c++filt | grep 'ssgVtxTable::ssgVtxTable'
U ssgVtxTable::ssgVtxTable(unsigned long, ...as above...)
and the linker does not find this in the dynamic library (plib framework).
Static linking finds the "unsigned int" version OK, and dynamic
linking is looking for "unsigned long". I've looked through project
settings and compiler options, but I didn't find anything relevant.
Any ideas?
thanks,
-Brent
|
|
From: Brent B. <bre...@gm...> - 2009-03-04 23:29:17
|
A couple weeks ago I asked about OS X port, and saw the responses
here. I've also been in contact with Steve Hudson about it, and have
gotten a running version. With a few other tweaks, I got the trackgen
program built and seemingly usable.
I'm building on new macbook, leopard 10.5.6, XCode 3.1.2 (GCC 4.0.1),
and have set the project default architectures to be "Universal
32-bit" (i386/ppc). Oh, this is the 1.3.0 Torcs source.
There are some odd intermittant linkage problems that I haven't
figured out yet. At one point, I was able to get a full, clean build
of everything in the projects that Steve shared, but it's eluding me
now. The ssggraph.so project is the epicenter of the 6 linkage
problems.
Two errors are this:
"ssgVtxTable::ssgVtxTable(unsigned long, ssgVertexArray*,
ssgNormalArray*, ssgTexCoordArray*, ssgColourArray*)", referenced
from:
initWheel(CarElt*, int)in grcar.o
initBackground() in grscene.o
... etc
Other errors are GCC "vtable of" errors. Here's a complete error:
"ssgSimpleState::isEnabled(unsigned long)", referenced from:
vtable for grMultiTexState in grmultitexstate.o
vtable for grManagedState in grtexture.o
The GCC vtable issue is this: when a class is declared in a header
file AND has virtual methods with the function body defined in the
header also, GCC will not generate a vtable anywhere. GCC requires at
least one of the virtual functions to have an implementation in a
compilation unit (.cpp), and GCC will place the vtable in that unit's
object file. A class defined like the following will generate this
error:
/* Foo.h */
class Foo {
public:
~Foo() {}
};
To fix it, just move any virtual function body out of the header, and
into a .cpp file somewhere. I made this change to the grManagedState
class (grtexture.h, grtexture.cpp) and that cleared up about half of
the specific error locations. Ditto for grMultiTexState. I'm stumped
as to what is causing the remaining vtable issues.
Has anybody else been trying out the OS X builds, and if they are
working for you, what's your hardware and versions?
BTW, I also fetched the plib-185 disk image Steve shared, and rebuilt
that framework ensuring the GCC arches and SDK version matched Torcs.
No change, as it matched OK.
-Brent
p.s. $ gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
|
|
From: Stephen D. H. <shu...@uw...> - 2009-03-01 04:03:07
|
Hi, It looks like I forgot to cc the list before. A download link to the XCode project for Torcs 1.3.0 is below. Steve Begin forwarded message: > From: "Stephen D. Hudson" <shu...@uw...> > Date: February 14, 2009 8:39:12 PM GMT-05:00 > To: be...@bl... > Subject: Re: [Torcs-devel] Torcs Universal Binary for Mac OS X 10.5 > > Hi Bernhard, > > Here is the most recent archive from Luca with his changes: > http://www.megaupload.com/?d=WVWOQAZ3 > It contains the source code for Torcs 1.3.0 and XCode projects for > Torcs and the robots. > > It should compile much faster on your new Macbook than it does on my > old G5 iMac. I'll try to apply our changes to the source for > version 1.3.1. > > Have fun, > > Steve > > On 14-Feb-09, at 2:26 PM, Bernhard Wymann wrote: > >> Hi Stephen >> >>> Both Luca and I have successfully compiled Torcs on Mac OS X >>> 10.5. All >>> of the dependencies have been compiled as frameworks that can be >>> included in the Torcs application bundle. Luca has taken care of >>> the >>> Mac specific issues such as correctly saving preferences and >>> ensuring >>> that everything is properly compiled as universal binaries. This >>> means >>> that Mac users will be able to run Torcs without compiling or >>> configuring anything. >> >> Great (I bought a MacBook 2 weeks ago) :-) >> >>> At this stage, a Mac binary package that should run on any PPC or >>> Intel >>> OS X 10.5 sytem is ready (or nearly ready). Because the package has >>> reached a mature state and there are others interested, we would >>> like to >>> make the package available via Sourceforge for wider testing. We >>> would >>> also like to make the XCode projects and source code changes >>> available >>> on Sourceforge. This will give everyone an opportunity to >>> incorporate >>> the changes in the official code and to get started on version >>> 1.3.1 for >>> Mac. This will probably also be useful for building torcs-ng. >>> >>> How can we go about getting everything on sourceforge? >> >> Can you put your packages somewhere where I can fetch it, I would >> put it then on >> sf.net. It would be cool if you could make as well a diff to the >> actual TORCS >> 1.3.1 package, such that people can build the version by >> themselves. A little >> README or something would help as well. >> >> Thank you, best regards >> >> Bernhard >> >> ------------------------------------------------------------------------------ >> Open Source Business Conference (OSBC), March 24-25, 2009, San >> Francisco, CA >> -OSBC tackles the biggest issue in open source: Open Sourcing the >> Enterprise >> -Strategies to boost innovation and cut costs with open source >> participation >> -Receive a $600 discount off the registration fee with the source >> code: SFAD >> http://p.sf.net/sfu/XcvMzF8H >> _______________________________________________ >> Torcs-devel mailing list >> Tor...@li... >> https://lists.sourceforge.net/lists/listinfo/torcs-devel > > ------------------------------------------------------------------------------------------------------------ > Stephen Hudson Lab: > (519) 661-2111 x85035 > Department of Physics and Astronomy Office: (519) 661-2111 x86436 > The University of Western Ontario Web: http://publish.uwo.ca/~shudson2 > London, ON, N6A 3K7 Email: shu...@uw... > ------------------------------------------------------------------------------------------------------------ > ------------------------------------------------------------------------------------------------------------ Stephen Hudson Lab: (519) 661-2111 x85035 Department of Physics and Astronomy Office: (519) 661-2111 x86436 The University of Western Ontario Web: http://publish.uwo.ca/~shudson2 London, ON, N6A 3K7 Email: shu...@uw... ------------------------------------------------------------------------------------------------------------ |