Hi James, et all.
First off I have to say that James, Adam and Chris, I really appreciate the work you are doing on the OSX port and I think it is of great value to the community. I understand that this development process is difficult, and keeping the cvs working on both sides (linux and osx+others) when all the develppers don't have access to all the OSs is a great challange. I know the last time I tried to use the CVS version on linux, the pix_movie stuff was broken under linux. I don't mean this to be a blame thing, but it is in all our best interests that the changes made are not breaking stuff that had previously worked.
I do think a more verbose dialog between developers may help the issues you describe. Any other opinions?
B.
----- Original Message ----- From: tigital tigital@mac.com Date: Monday, December 16, 2002 9:46 am Subject: [PD-dev] [GEM] new postrender crashes OS X
hello,
...I'm really not sure what or why IOhannes is doing some of these changes? So far, they have led to crashes and instability on the Mac OS X port. Thanks. I am frustrated, because things that worked no longer function correctly! What makes it worse is that these changes are done without any announcement or warning, unless you watch the cvs logs daily...and even then, the logs are not specific to changes in a file, and do not give any insight to the scope of the changes...
...the first problem came when IOhannes decided to rewrite the processImage() system: thankfully, he tried to hide most of this within #ifdef NEW_DUAL_PIX, but there was no discussion as to the thought behind this...
...then he filed a rewrite of rendering:
deleted pix_fx the pix_fx functionality is now in GemPixObj this functionality is: save the image-state before it is processed and reconstruct it in the postrender function so we can change size/format and even bend the data-pointer and objects "before" will not notice (and crash)
...this is the cause of my crashes...previously, I could switch out movies on the fly when doing dual processing; now we get segfaults when there is no "old_data"...and this change was supposed to fix a crash? haha
...I don't see how Mac OS X support for GEM can continue without a little discussion before unilaterally making changes to cvs that affect all platforms...
l8r, jamie
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
On Mon, 16 Dec 2002 bbogart@ryerson.ca wrote:
Hi James, et all.
First off I have to say that James, Adam and Chris, I really appreciate the work you are doing on the OSX port and I think it is of great value to the community. I understand that this development process is difficult, and keeping the cvs working on both sides (linux and osx+others) when all the develppers don't have access to all the OSs is a great challange. I know the last time I tried to use the CVS version on linux, the pix_movie stuff was broken under linux. I don't mean this to be a blame thing, but it is in all our best interests that the changes made are not breaking stuff that had previously worked.
I do think a more verbose dialog between developers may help the issues you describe. Any other opinions?
A slighlty different proposal. Having taken a closer look at Gem, and specifically pix_ processing, I do completely understand that Johannes wants to change everything in there. There is no way around introducing bugs in this process.
In order to make this transition less painfull, we could make a stable branch of Gem, which will only change for bugfixes, build system enhancements etc (no new features !!).
This means of course that there will be no yuv support.
Is there a need for such a branch ?
Guenter
B.
----- Original Message ----- From: tigital tigital@mac.com Date: Monday, December 16, 2002 9:46 am Subject: [PD-dev] [GEM] new postrender crashes OS X
hello,
...I'm really not sure what or why IOhannes is doing some of these changes? So far, they have led to crashes and instability on the Mac OS X port. Thanks. I am frustrated, because things that worked no longer function correctly! What makes it worse is that these changes are done without any announcement or warning, unless you watch the cvs logs daily...and even then, the logs are not specific to changes in a file, and do not give any insight to the scope of the changes...
...the first problem came when IOhannes decided to rewrite the processImage() system: thankfully, he tried to hide most of this within #ifdef NEW_DUAL_PIX, but there was no discussion as to the thought behind this...
...then he filed a rewrite of rendering:
deleted pix_fx the pix_fx functionality is now in GemPixObj this functionality is: save the image-state before it is processed and reconstruct it in the postrender function so we can change size/format and even bend the data-pointer and objects "before" will not notice (and crash)
...this is the cause of my crashes...previously, I could switch out movies on the fly when doing dual processing; now we get segfaults when there is no "old_data"...and this change was supposed to fix a crash? haha
...I don't see how Mac OS X support for GEM can continue without a little discussion before unilaterally making changes to cvs that affect all platforms...
l8r, jamie
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
PD-dev mailing list PD-dev@iem.kug.ac.at http://iem.kug.ac.at/cgi-bin/mailman/listinfo/pd-dev
A slighlty different proposal. Having taken a closer look at Gem, and specifically pix_ processing, I do completely understand that Johannes wants to change everything in there. There is no way around introducing bugs in this process.
In order to make this transition less painfull, we could make a stable branch of Gem, which will only change for bugfixes, build system enhancements etc (no new features !!).
This means of course that there will be no yuv support.
Is there a need for such a branch ?
Interesting proposition Guenter. Maybe a stable and 'experimental' branch could help ease transitions in code additions. Another idea might be to have a 'Core' Gem version that's cross-platform with extra extensions to accommodate differences and unique features for each OS. That might alleviate some of our problems. The counterpoint is that it would mean more work for administrators and potential confusion for users. Some thing to think about...
cgc
Guenter
-
bbogart＠ryerson.ca -
chris clepper -
guenter geiger