Hello,
Compiling Gem on OSX 10.9 is littered with these errors:
"error: addition of default argument on redeclaration makes this constructor a default constructor"
There is discussion about this here: http://stackoverflow.com/questions/18313509/default-argument-gcc-vs-clang
I understand what is happening but I do not know how to properly fix this. For example if in:
src/Controls/gemlist_info.cpp ->
gemlist_info :: gemlist_info (t_floatarg arg0=0) {
src/Controls/gemlist_info.h ->
gemlist_info (t_floatarg); // CON
I am able to compile without error if I do:
src/Controls/gemlist_info.cpp ->
gemlist_info :: gemlist_info (t_floatarg) {
src/Controls/gemlist_info.h -> g emlist_info (t_floatarg arg0=0); // CON
BUT in a more complicated example where there might be (t_floatarg arg0=0, t_floatarg arg1=0, t_floatarg arg2=0)
How do I fix?
Basically more than half the src/opengl/*.cpp &*.h have this issue.
Any fix should be compatible with GCC.
I have cloned Gem from github repo and have created a new branch (osx_10.9_x64) to comit my efforts.
Thanks! m
On 2014-01-05 21:38, me.grimm wrote:
I understand what is happening but I do not know how to properly fix this. For example if in:
src/Controls/gemlist_info.cpp ->
gemlist_info :: gemlist_info (t_floatarg arg0=0) {
src/Controls/gemlist_info.h ->
gemlist_info (t_floatarg); // CON
I am able to compile without error if I do:
src/Controls/gemlist_info.cpp ->
gemlist_info :: gemlist_info (t_floatarg) {
src/Controls/gemlist_info.h -> gemlist_info (t_floatarg arg0=0); // CON
this is correct. the original code is bogus.
however, since the default args were only ever declared in the class definitions, they could not have been used anywhere... this basically means, that it should be safe to simply remove all erroneous default arguments.
src/Controls/gemlist_info.cpp ->
gemlist_info :: gemlist_info (t_floatarg arg0) {
and leave the header alone: src/Controls/gemlist_info.h ->
gemlist_info (t_floatarg); // CON
BUT in a more complicated example where there might be (t_floatarg arg0=0, t_floatarg arg1=0, t_floatarg arg2=0)
How do I fix?
Basically more than half the src/opengl/*.cpp &*.h have this issue.
the same as above.
Any fix should be compatible with GCC.
and with M$VC.
I have cloned Gem from github repo and have created a new branch (osx_10.9_x64) to comit my efforts.
cool. just do a pull request once you are ready (and nobody else was faster...)
fgmadsr IOhannes
cool. just do a pull request once you are ready
done! compiled fine after the changes....
(and nobody else was faster...)
ha! i guess not!!!
m
On Mon, Jan 6, 2014 at 2:01 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 2014-01-05 21:38, me.grimm wrote:
I understand what is happening but I do not know how to properly fix
this.
For example if in:
src/Controls/gemlist_info.cpp ->
gemlist_info :: gemlist_info (t_floatarg arg0=0) {
src/Controls/gemlist_info.h ->
gemlist_info (t_floatarg); // CON
I am able to compile without error if I do:
src/Controls/gemlist_info.cpp ->
gemlist_info :: gemlist_info (t_floatarg) {
src/Controls/gemlist_info.h -> gemlist_info (t_floatarg arg0=0); // CON
this is correct. the original code is bogus.
however, since the default args were only ever declared in the class definitions, they could not have been used anywhere... this basically means, that it should be safe to simply remove all erroneous default arguments.
src/Controls/gemlist_info.cpp ->
gemlist_info :: gemlist_info (t_floatarg arg0) {
and leave the header alone: src/Controls/gemlist_info.h ->
gemlist_info (t_floatarg); // CON
BUT in a more complicated example where there might be (t_floatarg arg0=0, t_floatarg arg1=0, t_floatarg arg2=0)
How do I fix?
Basically more than half the src/opengl/*.cpp &*.h have this issue.
the same as above.
Any fix should be compatible with GCC.
and with M$VC.
I have cloned Gem from github repo and have created a new branch (osx_10.9_x64) to comit my efforts.
cool. just do a pull request once you are ready (and nobody else was faster...)
fgmadsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 2014-01-07 00:07, me.grimm wrote:
cool. just do a pull request once you are ready
done! compiled fine after the changes....
(and nobody else was faster...)
ha! i guess not!!!
thanks for the quick fixes. however, some of the patches are not in a form that i can accept :-(
+ ad5c6cd - adds a file "gemdefaultwindow.pd" which - has nothing to do with fixing the compilation problem - is generated during the build process (and will differ on various platforms) and is thus intentionally not included in the repository
+ 31b8bc0 - simply disables and thus breaks the functionality of the method it modifies
a more cosmetic remark: i would prefer to have more descriptive titles of the commits. e.g. "remove default arguments from definitions" rather than "Fix on error: addition of default argument on redeclaration makes this". the problem is mainly, that the title of the commit (the first line in the commit message) should be terse and not contain more than 50 characters.
these things are easy enough to fix (do a *mixed* reset of your branch to the split-point and factor new commits from there). i could do that myself, but then the authorship of the patches would be lost and i'd rather leave that intact, so you get proper credits for your work.
fgadsr IOhannes
cool got it! give me a couple of days. thanks for the help!!! it is a new years resolution to figure all this git stuff out....
these things are easy enough to fix (do a *mixed* reset of your branch
to the split-point and factor new commits from there).
i will give it a shot!!
i could do that myself, but then the authorship of the patches would be
lost and i'd rather leave that intact, so you get proper credits for your work.
thanks! i want to learn anyway and there is no better way to learn than to do....
m
On Tue, Jan 7, 2014 at 4:52 AM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 2014-01-07 00:07, me.grimm wrote:
cool. just do a pull request once you are ready
done! compiled fine after the changes....
(and nobody else was faster...)
ha! i guess not!!!
thanks for the quick fixes. however, some of the patches are not in a form that i can accept :-(
- ad5c6cd
- adds a file "gemdefaultwindow.pd" which
- has nothing to do with fixing the compilation problem
- is generated during the build process (and will differ on various
platforms) and is thus intentionally not included in the repository
- 31b8bc0
- simply disables and thus breaks the functionality of the method it
modifies
a more cosmetic remark: i would prefer to have more descriptive titles of the commits. e.g. "remove default arguments from definitions" rather than "Fix on error: addition of default argument on redeclaration makes this". the problem is mainly, that the title of the commit (the first line in the commit message) should be terse and not contain more than 50 characters.
these things are easy enough to fix (do a *mixed* reset of your branch to the split-point and factor new commits from there). i could do that myself, but then the authorship of the patches would be lost and i'd rather leave that intact, so you get proper credits for your work.
fgadsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
- 31b8bc0
- simply disables and thus breaks the functionality of the method it
modifies
yeah this is the error I am getting:
*videoBase.cpp:423:3: **error: **use of undeclared identifier 'select'*
select(0,0,0,0,&sleep);
any ideas how to fix?
m
On Tue, Jan 7, 2014 at 4:52 AM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 2014-01-07 00:07, me.grimm wrote:
cool. just do a pull request once you are ready
done! compiled fine after the changes....
(and nobody else was faster...)
ha! i guess not!!!
thanks for the quick fixes. however, some of the patches are not in a form that i can accept :-(
- ad5c6cd
- adds a file "gemdefaultwindow.pd" which
- has nothing to do with fixing the compilation problem
- is generated during the build process (and will differ on various
platforms) and is thus intentionally not included in the repository
- 31b8bc0
- simply disables and thus breaks the functionality of the method it
modifies
a more cosmetic remark: i would prefer to have more descriptive titles of the commits. e.g. "remove default arguments from definitions" rather than "Fix on error: addition of default argument on redeclaration makes this". the problem is mainly, that the title of the commit (the first line in the commit message) should be terse and not contain more than 50 characters.
these things are easy enough to fix (do a *mixed* reset of your branch to the split-point and factor new commits from there). i could do that myself, but then the authorship of the patches would be lost and i'd rather leave that intact, so you get proper credits for your work.
fgadsr IOhannes
GEM-dev mailing list GEM-dev@iem.at http://lists.puredata.info/listinfo/gem-dev
On 2014-01-11 19:06, me.grimm wrote:
- 31b8bc0
- simply disables and thus breaks the functionality of the method it
modifies
yeah this is the error I am getting:
*videoBase.cpp:423:3: **error: **use of undeclared identifier 'select'*
select(0,0,0,0,&sleep);
any ideas how to fix?
$ man select
and check which headers need to be included.
gfmar IOhannes
wow! that was easy! thanks! worked fine....
m
On Sat, Jan 11, 2014 at 1:28 PM, IOhannes m zmölnig zmoelnig@iem.at wrote:
On 2014-01-11 19:06, me.grimm wrote:
- 31b8bc0
- simply disables and thus breaks the functionality of the method it
modifies
yeah this is the error I am getting:
*videoBase.cpp:423:3: **error: **use of undeclared identifier 'select'*
select(0,0,0,0,&sleep);
any ideas how to fix?
$ man select
and check which headers need to be included.
gfmar IOhannes
On 01/07/2014 10:52 AM, IOhannes m zmölnig wrote:
these things are easy enough to fix (do a *mixed* reset of your branch to the split-point and factor new commits from there). i could do that myself, but then the authorship of the patches would be lost and i'd rather leave that intact, so you get proper credits for your work.
i'll try to explain what i mean by this. personally i'm using gitk (a graphical version browser) to navigate the history and move my repository to a given revision, whenever it becomes non-trivial. in this case, i would fire up gitk, place my cursor on revision 28f58f488 (which is the one were you branched off), right click and select "reset branch to here". i'l lbe given the choice of whether i want to do a "hard reset" (resetting working tree and index), a "soft reset" (leaving working tree and index untouched) and a "mixed reset" (leave working tree untouched, reset index). i'd chose "mixed reset", which results in having all the modified files in the working tree, but none of them committed yet.
git reset --mixed 28f58f488
then i'd start a new branch
git checkout -b "osx_fixes"
and start creating new "clean" commits, where each commit does only a "single thing" (though probably changing multiple files at once; e.g. i'd remove all the default arguments in a single commit).
if a single file has multiple changes in it (that should belong to multiple commits), then i'd use a graphical commit tool like: git gui (which allows me to commit single lines). you could also do this from the cmdline using git add -p thisfile.x
once this is done, i'd create *new* pull request on github and close the old one.
fgmadsr IOhannes
-
IOhannes m zmölnig -
me.grimm