So we keep talking and talking about a release of 0.888, and I think maybe just setting a date and sticking to it will actually make it happen. I propose two weeks from today December the 2nd to be that date. There's no reason it couldn't be done by next week, but two gives a bit more time for the loose ends.
The critical thing I see right now is making sure there is as much documentation in the release as possible. At the very least, every object should have a help file that lists all of the (working) features of the object. Here's a list of objects I don't have help for:
- curve3d - camera - pix_dv
I can also add my beginner tutorial to CVS, although it does contain images which would add a few hundred KB to the distribution.
Bug fixes/enhancements:
- pix_biquad does next to nothing now. The coefficients seem to determine how fast the image fades to black. I reverted two versions and it worked as it always has. Any ideas what's going on?
- pix_write gave me some serious trouble last night. if i didn't give it a 'file ' message it overwrote the pd binary!! that's some really bad news, and i've gone through 3 versions of pd in the last 24 hours. i'm not sure what's going on but the default setup no longer writes 'gem000x.tif' in pd/bin for some reason.
- i mixed up versions of pix_filmDarwin/YUV and need to get them sorted out.
- i will probably add some more Altivec code.
We need to decide where the binary distributions will reside. Sourceforge project page? IEM? Both? Somewhere else? Someone needs to build a version for OSX and a version for Windows by this weekend so we can check them on a few machines and be somewhat sure nothing is terribly wrong with them. A few changes and tweaks will probably be needed but there should be enough time to do them.
I think we should also plan on another point release by the beginning of next year to address problems with 0.888 (will it be 0.889 or 0.89?). Assuming we don't horribly fuck up 0.888 there won't be a huge rush for these fixes. I really want to put an end to getting bug reports on versions that are years out of date or come from some unknown origin.
Further down the road, 0.90 could be a major release incorporating large changes and additions like my vertex-array objects and shader support. I cannot reasonably estimate a time frame for that, although I am working towards making significant progress on the vertex stuff by year's end, and will commit code to CVS by then.
That's all I can think of right now.
cgc
chris clepper wrote:
The critical thing I see right now is making sure there is as much documentation in the release as possible. At the very least, every object should have a help file that lists all of the (working) features of the object. Here's a list of objects I don't have help for:
- curve3d
- camera
- pix_dv
their is a curve3d.pd patch in the usual place :
http://drpichon.free.fr/pure-data/GEM/curve3D/
that can be a good start for the help of this object...
does a standart for gem help file exist? sould I remove the gemwin in the help file or not? should I make some more changes?
cyrille
I can also add my beginner tutorial to CVS, although it does contain images which would add a few hundred KB to the distribution.
Bug fixes/enhancements:
- pix_biquad does next to nothing now. The coefficients seem to
determine how fast the image fades to black. I reverted two versions and it worked as it always has. Any ideas what's going on?
- pix_write gave me some serious trouble last night. if i didn't give
it a 'file ' message it overwrote the pd binary!! that's some really bad news, and i've gone through 3 versions of pd in the last 24 hours. i'm not sure what's going on but the default setup no longer writes 'gem000x.tif' in pd/bin for some reason.
- i mixed up versions of pix_filmDarwin/YUV and need to get them sorted
out.
- i will probably add some more Altivec code.
We need to decide where the binary distributions will reside. Sourceforge project page? IEM? Both? Somewhere else? Someone needs to build a version for OSX and a version for Windows by this weekend so we can check them on a few machines and be somewhat sure nothing is terribly wrong with them. A few changes and tweaks will probably be needed but there should be enough time to do them.
I think we should also plan on another point release by the beginning of next year to address problems with 0.888 (will it be 0.889 or 0.89?). Assuming we don't horribly fuck up 0.888 there won't be a huge rush for these fixes. I really want to put an end to getting bug reports on versions that are years out of date or come from some unknown origin.
Further down the road, 0.90 could be a major release incorporating large changes and additions like my vertex-array objects and shader support. I cannot reasonably estimate a time frame for that, although I am working towards making significant progress on the vertex stuff by year's end, and will commit code to CVS by then.
That's all I can think of right now.
cgc
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
hi
Cyrille Henry wrote:
their is a curve3d.pd patch in the usual place :
i just forgot to submit these....
that can be a good start for the help of this object...
does a standart for gem help file exist?
well, i think the new help-files (like help/cube.pd) are quite ok
sould I remove the gemwin in the help file or not?
the new help patches are all working examples including [gemwin]
should I make some more changes?
if you like to: explain what is being done and what means what in text... but the help patch is fine as a starter
mfg.as.dr IOhannes
ok, I'll try to make this change in the next few days.
looking at the patch, I think that I did'nt make the good choice for the messages send to the object. specially the "res" message. I fink "resolution" can be better? or maybe someone can think to something else????
cyrille
IOhannes zmoelnig wrote:
hi
Cyrille Henry wrote:
their is a curve3d.pd patch in the usual place :
i just forgot to submit these....
that can be a good start for the help of this object...
does a standart for gem help file exist?
well, i think the new help-files (like help/cube.pd) are quite ok
sould I remove the gemwin in the help file or not?
the new help patches are all working examples including [gemwin]
should I make some more changes?
if you like to: explain what is being done and what means what in text... but the help patch is fine as a starter
mfg.as.dr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
hello,
I just upload on the usual place the last curve3d.pd patch.
I think this file can be use for the help file. can someone have a look and commit to the CVS or tell me what to change?
thanks
Cyrille
Cyrille Henry wrote:
ok, I'll try to make this change in the next few days.
looking at the patch, I think that I did'nt make the good choice for the messages send to the object. specially the "res" message. I fink "resolution" can be better? or maybe someone can think to something else????
cyrille
IOhannes zmoelnig wrote:
hi
Cyrille Henry wrote:
their is a curve3d.pd patch in the usual place :
i just forgot to submit these....
that can be a good start for the help of this object...
does a standart for gem help file exist?
well, i think the new help-files (like help/cube.pd) are quite ok
sould I remove the gemwin in the help file or not?
the new help patches are all working examples including [gemwin]
should I make some more changes?
if you like to: explain what is being done and what means what in text... but the help patch is fine as a starter
mfg.as.dr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
hi,
compiling gem-cvs from yesterday works now fine with guenters suggestion about time.h . but: curve3d compiles but cannot be created, is anyone experiencing the same ?
best
erich
I'm using it fine on my machine at work, but I added it to an pre-curve3D version of CVS manually. I had to add string.h and define the min and max macros to get it to compile, but the object gets created and works fine...
Ben
hi,
compiling gem-cvs from yesterday works now fine with guenters suggestion about time.h . but: curve3d compiles but cannot be created, is anyone experiencing the same ?
best
erich
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
i belive that, but with cvs i have different experiance
e
---------------------------------- http://randomseed.org
On Thu, 20 Nov 2003 ben@ekran.org wrote:
I'm using it fine on my machine at work, but I added it to an pre-curve3D version of CVS manually. I had to add string.h and define the min and max macros to get it to compile, but the object gets created and works fine...
Ben
hi,
compiling gem-cvs from yesterday works now fine with guenters suggestion about time.h . but: curve3d compiles but cannot be created, is anyone experiencing the same ?
best
erich
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
Quoting rat@telecoma.net:
i belive that, but with cvs i have different experiance
e
i just built, loaded and played with curve3d from the CVS on OSX. Objects should auto-register now thanks th Guenter.
cgc
On Thu, 20 Nov 2003 ben@ekran.org wrote:
I'm using it fine on my machine at work, but I added it to an
pre-curve3D
version of CVS manually. I had to add string.h and define the min and
max
macros to get it to compile, but the object gets created and works
fine...
Ben
hi,
compiling gem-cvs from yesterday works now fine with guenters suggestion about time.h . but: curve3d compiles but cannot be created, is anyone experiencing
the
same ?
best
erich
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
hi,
:-) there is no bug with curve3d in current cvs, i was just stupid.
sorry
erich
At 9:23 PM +0100 11/18/03, guenter geiger wrote:
On Tue, 18 Nov 2003, chris clepper wrote:
So we keep talking and talking about a release of 0.888
Is there a special reason for the version number 0.888 instead of 0.88 ? I fear this might be a bit confusing for the user. (Well, it is for me, too)
IOhannes has been using that number for a while. To be perfectly honest, I don't really care what we call it as long as we call it an 'official release'.
cgc
Guenter
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
chris clepper wrote:
At 9:23 PM +0100 11/18/03, guenter geiger wrote:
On Tue, 18 Nov 2003, chris clepper wrote:
So we keep talking and talking about a release of 0.888
Is there a special reason for the version number 0.888 instead of 0.88 ?
IOhannes has been using that number for a while. To be perfectly honest, I don't really care what we call it as long as we call it an 'official release'.
well, actually there have been very big changes from 0.87 to the next release (however it will be called) i thought of expressing these in the version-number somehow and i don't want to do "1.0" (afraid) and 0.888 probably gives us even more time to reach 1.0 (112 versions more to go instead of 12)
that is all
mfg.a.sdr IOhannes
goodnight
cgc
On Tue, 18 Nov 2003, IOhannes zmoelnig wrote:
and 0.888 probably gives us even more time to reach 1.0 (112 versions more to go instead of 12)
Mhh, you mean skipping 800 release numbers gives us more time ? Well, I see that you are thinking of the release numbers as decimal. I'm not sure if this is really common. (e.g 2.4.9 is lower than 2.4.10 in linux world)
Guenter
that is all
mfg.a.sdr IOhannes
goodnight
cgc
Well, I see that you are thinking of the release numbers as decimal. I'm not sure if this is really common. (e.g 2.4.9 is lower than 2.4.10 in linux world)
which is true. but i feel somehow (and i think i have seen it, even in linux world), that the successor of 0.99 is rather 1.0 than 0.100
anyhow, i think the argument with "big changes" might be a better one, as it is really more than just the successor of 0.87, and skipping single version numbers (like 0.90) seems even worse. and 0.888 is such a beautiful number
mfg.a.dsr IOhannes
On Wed, 19 Nov 2003, Johannes M Zmoelnig wrote:
and 0.888 is such a beautiful number
jaja, eighth son of an eighth son of an eighth son ...
mfg.a.dsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
Quoting Johannes M Zmoelnig zmoelnig@iem.kug.ac.at:
Well, I see that you are thinking of the release numbers as decimal. I'm not sure if this is really common. (e.g 2.4.9 is lower than
2.4.10
in linux world)
which is true. but i feel somehow (and i think i have seen it, even in linux world), that the successor of 0.99 is rather 1.0 than 0.100
anyhow, i think the argument with "big changes" might be a better one, as it is really more than just the successor of 0.87, and skipping single version numbers (like 0.90) seems even worse.
Ok so it is a big change, but a _major_ reason for that is how long we've been putting this off. It doesn't really matter what the version number is because if we contiue at this rate the 12 releases until 1.0 wouldn't happen until we are all old men!! I don't think we have to fear a 1.0 release in any way. GEM is really getting to the point that it compares pretty well to commercial packages.
So what say you about a release on December 2nd?
and 0.888 is such a beautiful number
The Illinois Pick 3 lotto on Monday night was 0 8 8, so there's a counter argument for you! ;)
cgc
mfg.a.dsr IOhannes
I'm looking over the changes made for pix_texture concerning the 'debug' post() statements, and think I have a solution to the problem. While post() is great for debugging and giving info about various internal states in GEM objects, it becomes annoying and in some cases highly objectionable to have all this data spewed out into the terminal window. What if we make a debug function part of the pix base class that would dump the state info on request? This way if a user wants to find out what the heck is going on in their chain and perhaps figure out why it's not working, they could send a 'debug' message to the object.
Here's some code to illustrate:
void pix_texture :: doDebug(GemState *state){
if ( GemMan::texture_range_supported && GemMan::texture_rectangle_supported && m_mode){ post("pix_texture: using glTextureRangeAPPLE()"); } else { post("pix_texture: using TEXTURE_2D"); } }
There would be a m_doDebug that would trigger with the 'debug' message and be reset in the post render to prevent endless retriggers.
This would help reduce code clutter and also allow for errors and checks that occur render pass to be managed without throwing one every single time the render function is called. Also, if an entire chain is sent 'debug' messages then the user would have a good set of info to trace problems with and also post to the list for help.
This will probably require a few more member variables in each class, but it might provide a much more elegant solution to our post() and debug problems.
cgc
chris clepper wrote:
I'm looking over the changes made for pix_texture concerning the 'debug' post() statements, and think I have a solution to the problem. While post() is great for debugging and giving info about various internal
to be precise: "post()" is far from being great for debugging. i'd really love a "debug()" function that is exported from pd, so externals could make use of the various debug-levels that can be specified as startup-arguments of pd.
we could then let the user set the debug-level of a certain gem-object (in m_doDebug).
mfg.a.sdr IOhannes
On Wed, 19 Nov 2003, chris clepper wrote:
void pix_texture :: doDebug(GemState *state){
if ( GemMan::texture_range_supported && GemMan::texture_rectangle_supported && m_mode){ post("pix_texture: using glTextureRangeAPPLE()"); } else { post("pix_texture: using TEXTURE_2D"); } }
There would be a m_doDebug that would trigger with the 'debug' message and be reset in the post render to prevent endless retriggers.
Thats a good idea, make m_debug a int which indicates the level as Johannes suggested.
Guenter
hi,
i tried to compile gem-cvs with gcc-3.2 from today 15h (vienna,berlin, oslo etc :-), is it me or a bug in cvs ?
cheers e
following errors:
-------------------------------
In file included from /usr/include/linux/videodev2.h:16, from /usr/include/linux/videodev.h:8, from pix_videoLinux.h:32, from pix_videoLinux.cpp:46: /usr/include/linux/time.h:9: error: redefinition of `struct timespec' /usr/include/time.h:119: error: previous definition of `struct timespec' /usr/include/linux/time.h:15: error: redefinition of `struct timeval' /usr/include/bits/time.h:70: error: previous definition of `struct timeval' /usr/include/linux/time.h:20: error: redefinition of `struct timezone' /usr/include/sys/time.h:57: error: previous definition of `struct timezone' /usr/include/linux/time.h:359: error: redefinition of `struct itimerval' /usr/include/sys/time.h:108: error: previous definition of `struct itimerval' In file included from /usr/include/pthread.h:21, from pix_videoLinux.h:34, from pix_videoLinux.cpp:46: /usr/include/time.h:160: error: redefinition of `struct itimerspec' /usr/include/linux/time.h:354: error: previous definition of `struct itimerspec ' In file included from /usr/include/linux/videodev2.h:16, from /usr/include/linux/videodev.h:8, from ../Pixes/videoV4L.h:34, from pix_videoNEW.cpp:18: /usr/include/linux/time.h:9: error: redefinition of `struct timespec' /usr/include/time.h:119: error: previous definition of `struct timespec' /usr/include/linux/time.h:15: error: redefinition of `struct timeval' /usr/include/bits/time.h:70: error: previous definition of `struct timeval' /usr/include/linux/time.h:20: error: redefinition of `struct timezone' /usr/include/sys/time.h:57: error: previous definition of `struct timezone' /usr/include/linux/time.h:359: error: redefinition of `struct itimerval' /usr/include/sys/time.h:108: error: previous definition of `struct itimerval' c++ -c -g -fPIC -mmmx -DHAVE_MMX -I../ -I/usr/include/avifile-0.7 -I/usr/include/freetype2/ -fno-builtin -O3 -funroll-loops -ffast-math pix_videoNT.cpp -o pix_vid eoNT.o In file included from /usr/include/pthread.h:21, from ../Pixes/videoV4L.h:37, from pix_videoNEW.cpp:18: /usr/include/time.h:160: error: redefinition of `struct itimerspec'
On Wed, 19 Nov 2003 rat@telecoma.net wrote:
hi,
i tried to compile gem-cvs with gcc-3.2 from today 15h (vienna,berlin, oslo etc :-), is it me or a bug in cvs ?
Its a bug in debians glibc-kernel-headers ... ( a long story ...) as a quick fix, exchange linux/time.h with time.h in /usr/include/linux/videodev2.h
G.
cheers e
following errors:
In file included from /usr/include/linux/videodev2.h:16, from /usr/include/linux/videodev.h:8, from pix_videoLinux.h:32, from pix_videoLinux.cpp:46: /usr/include/linux/time.h:9: error: redefinition of `struct timespec' /usr/include/time.h:119: error: previous definition of `struct timespec' /usr/include/linux/time.h:15: error: redefinition of `struct timeval' /usr/include/bits/time.h:70: error: previous definition of `struct timeval' /usr/include/linux/time.h:20: error: redefinition of `struct timezone' /usr/include/sys/time.h:57: error: previous definition of `struct timezone' /usr/include/linux/time.h:359: error: redefinition of `struct itimerval' /usr/include/sys/time.h:108: error: previous definition of `struct itimerval' In file included from /usr/include/pthread.h:21, from pix_videoLinux.h:34, from pix_videoLinux.cpp:46: /usr/include/time.h:160: error: redefinition of `struct itimerspec' /usr/include/linux/time.h:354: error: previous definition of `struct itimerspec ' In file included from /usr/include/linux/videodev2.h:16, from /usr/include/linux/videodev.h:8, from ../Pixes/videoV4L.h:34, from pix_videoNEW.cpp:18: /usr/include/linux/time.h:9: error: redefinition of `struct timespec' /usr/include/time.h:119: error: previous definition of `struct timespec' /usr/include/linux/time.h:15: error: redefinition of `struct timeval' /usr/include/bits/time.h:70: error: previous definition of `struct timeval' /usr/include/linux/time.h:20: error: redefinition of `struct timezone' /usr/include/sys/time.h:57: error: previous definition of `struct timezone' /usr/include/linux/time.h:359: error: redefinition of `struct itimerval' /usr/include/sys/time.h:108: error: previous definition of `struct itimerval' c++ -c -g -fPIC -mmmx -DHAVE_MMX -I../ -I/usr/include/avifile-0.7 -I/usr/include/freetype2/ -fno-builtin -O3 -funroll-loops -ffast-math pix_videoNT.cpp -o pix_vid eoNT.o In file included from /usr/include/pthread.h:21, from ../Pixes/videoV4L.h:37, from pix_videoNEW.cpp:18: /usr/include/time.h:160: error: redefinition of `struct itimerspec'
GEM-dev mailing list GEM-dev@iem.at http://iem.at/cgi-bin/mailman/listinfo/gem-dev
-
ben＠ekran.org -
cgc＠humboldtblvd.com -
chris clepper
-
Cyrille Henry -
guenter geiger -
IOhannes zmoelnig -
Johannes M Zmoelnig
-
rat＠telecoma.net