Pd-dev March 2003

pd-dev@lists.iem.at

24 participants
34 discussions

sf bug tracking
by Hans-Christoph Steiner 04 Mar '03

04 Mar '03

Since the topic came up, I thought I'd get the ball rolling. We need to figure out a few things in order to set up the SourceForge bug tracking. Here are the menus that need to be set up for the Bug Tracker: Categories Add categories like each directory in the base of the CVS: Framestein, abstractions, doc, externals, gem, htdocs, pd, xgui,(more?) Group Add groups like, 'v0.36','extended','unsupported',','unverified', etc Canned Response generic response messages for the tracker Users for BugTracker i.e. people who can have bugs assigned to them (everyone?) .hc

4 10

Doc Mgr, Tasks, Lists, and Forums on SourceForge Site
by Hans-Christoph Steiner 04 Mar '03

04 Mar '03

I turned off the features that we aren't currently using on the SourceForge project site. It makes the navigation cleaner, and makes the site look better, since the unused stuff will be hidden rather than popping up a page saying its empty. This is what I turned off (you do this under Admin-> Public Info): Doc Mgr, Tasks, Lists, and Forums. The Forums are set up put there aren't any posts in them. Plus I think we should instead direct people to the pd lists at iem.at to keep the community together. But if others disagree its easy to turn them on again. Its not possible to hide Support unfortunately... .hc

1 0

file releases on sourceforge
by Hans-Christoph Steiner 03 Mar '03

03 Mar '03

I was thinking of putting up some binary releases up on the SourceForge Files section. Anyone have any objections? I know a bunch of people who are interested in learning pd but are definitely not the type to download and compile things for themselves. It would be nice to have a central location to point people at for all of the various binaries, like RPMs, MacOS X packages, Win32 package/zip. .hc

5 16

[GEM] GEM CVS... x-platform issues
by Daniel Heckenberg 03 Mar '03

03 Mar '03

Hi GEM developers, I've recently (finally!) worked to make the CVS version of GEM actually build and run under Windows. There's lots of exciting new stuff in there which is good to see. The real-time graph updating is certainly an improvement. Tweaking GEM to build was not a particularly difficult experience but there are a few little issues that may bite (mainly caused by deficiencies in Windows and VC++ I might add). For the time being, I'll keep fiddling with others' source changes in such a way to make them build under Windows without breaking them on other platforms. Apologies in advance if I do, however, wreak havoc. Here are a couple of the issues if you want to try to avoid them... 1) Problem: 'for' scoping for VC++ 6.0 isn't compatible with the "new ISO" style scoping that GCC seems to support/default to. E.g. for (int i=0; i < i_max; i++) func(i); for (int I=0; i < i_MAX; i++) // causes VC++ redefinition error func2(i); Short-term Solution: I just removed any variable redefinitions that caused compiler errors under VC++. This may now result in warnings on other platforms. This is undesirable and I don't want to suggest that the code should conform to VC++ non-conformance... Long-term Solution: We probably should code to avoid both the VC++ error and the GCC warning. 2) Problem: Windows needs to have <windows.h> explicitly included before many of the "platform independent" GL headers (e.g. gl.h, glu.h etc). Short-term Solution: I added the #ifdef _WINDOWS etc. inclusion of windows.h wherever it's need... including the "I hate windows, I shouldn't have to do this". Whose immortal words are those, anyway?! Long-term Solution: I'll see if it's easy to add windows.h as a default include somehow so we can avoid pollution of the GEM source. OTOH, this causes a bit of obfuscation and "make" builds would be complicated.... That's enough for now, Daniel

4 9

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev March 2003