supernova compilation error #1794

nhthn · 2016-01-16T00:51:11Z

On 32-bit Ubuntu. A clean build with the latest master fails with the following error:

In file included from /home/nathan/src/supercollider/server/supernova/sc/sc_synthdef.hpp:29:0,
                 from /home/nathan/src/supercollider/server/supernova/sc/sc_synth_definition.hpp:24,
                 from /home/nathan/src/supercollider/server/supernova/sc/sc_synth.hpp:29,
                 from /home/nathan/src/supercollider/server/supernova/sc/sc_synth_definition.cpp:24:
/home/nathan/src/supercollider/server/supernova/./utilities/malloc_aligned.hpp:52:73: warning: ‘assume_aligned’ attribute directive ignored [-Wattributes]
 inline void* MALLOC ASSUME_ALIGNED(64) malloc_aligned(std::size_t nbytes)
                                                                         ^
In file included from /home/nathan/src/supercollider/external_libraries/boost/boost/config.hpp:39:0,
                 from /home/nathan/src/supercollider/external_libraries/boost/boost/filesystem/operations.hpp:18,
                 from /home/nathan/src/supercollider/server/supernova/sc/sc_synth_definition.cpp:22:
/home/nathan/src/supercollider/external_libraries/boost/boost/config/compiler/gcc.hpp:95:45: error: expected identifier before numeric constant
 #define BOOST_LIKELY(x) __builtin_expect(x, 1)
                                             ^
/home/nathan/src/supercollider/server/supernova/./utilities/branch_hints.hpp:24:21: note: in expansion of macro ‘BOOST_LIKELY’
 #define likely(x)   BOOST_LIKELY(x)
                     ^
/home/nathan/src/supercollider/external_libraries/nova-tt/nova-tt/branch_hints.hpp:28:13: note: in expansion of macro ‘likely’
 inline bool likely(bool expr)
             ^
/home/nathan/src/supercollider/external_libraries/boost/boost/config/compiler/gcc.hpp:95:45: error: expected ‘,’ or ‘...’ before numeric constant
 #define BOOST_LIKELY(x) __builtin_expect(x, 1)
                                             ^
/home/nathan/src/supercollider/server/supernova/./utilities/branch_hints.hpp:24:21: note: in expansion of macro ‘BOOST_LIKELY’
 #define likely(x)   BOOST_LIKELY(x)
                     ^
/home/nathan/src/supercollider/external_libraries/nova-tt/nova-tt/branch_hints.hpp:28:13: note: in expansion of macro ‘likely’
 inline bool likely(bool expr)
             ^
/home/nathan/src/supercollider/external_libraries/boost/boost/config/compiler/gcc.hpp:96:47: error: expected identifier before numeric constant
 #define BOOST_UNLIKELY(x) __builtin_expect(x, 0)
                                               ^
/home/nathan/src/supercollider/server/supernova/./utilities/branch_hints.hpp:25:21: note: in expansion of macro ‘BOOST_UNLIKELY’
 #define unlikely(x) BOOST_UNLIKELY(x)
                     ^
/home/nathan/src/supercollider/external_libraries/nova-tt/nova-tt/branch_hints.hpp:38:13: note: in expansion of macro ‘unlikely’
 inline bool unlikely(bool expr)
             ^
/home/nathan/src/supercollider/external_libraries/boost/boost/config/compiler/gcc.hpp:96:47: error: expected ‘,’ or ‘...’ before numeric constant
 #define BOOST_UNLIKELY(x) __builtin_expect(x, 0)
                                               ^
/home/nathan/src/supercollider/server/supernova/./utilities/branch_hints.hpp:25:21: note: in expansion of macro ‘BOOST_UNLIKELY’
 #define unlikely(x) BOOST_UNLIKELY(x)
                     ^
/home/nathan/src/supercollider/external_libraries/nova-tt/nova-tt/branch_hints.hpp:38:13: note: in expansion of macro ‘unlikely’
 inline bool unlikely(bool expr)
             ^
/home/nathan/src/supercollider/external_libraries/nova-tt/nova-tt/branch_hints.hpp: In function ‘bool nova::nova_tt::__builtin_expect(bool, int)’:
/home/nathan/src/supercollider/external_libraries/boost/boost/config/compiler/gcc.hpp:96:27: error: redefinition of ‘bool nova::nova_tt::__builtin_expect(bool, int)’
 #define BOOST_UNLIKELY(x) __builtin_expect(x, 0)
                           ^
/home/nathan/src/supercollider/server/supernova/./utilities/branch_hints.hpp:25:21: note: in expansion of macro ‘BOOST_UNLIKELY’
 #define unlikely(x) BOOST_UNLIKELY(x)
                     ^
/home/nathan/src/supercollider/external_libraries/nova-tt/nova-tt/branch_hints.hpp:38:13: note: in expansion of macro ‘unlikely’
 inline bool unlikely(bool expr)
             ^
/home/nathan/src/supercollider/external_libraries/boost/boost/config/compiler/gcc.hpp:95:25: error: ‘bool nova::nova_tt::__builtin_expect(bool, int)’ previously defined here
 #define BOOST_LIKELY(x) __builtin_expect(x, 1)
                         ^
/home/nathan/src/supercollider/server/supernova/./utilities/branch_hints.hpp:24:21: note: in expansion of macro ‘BOOST_LIKELY’
 #define likely(x)   BOOST_LIKELY(x)
                     ^
/home/nathan/src/supercollider/external_libraries/nova-tt/nova-tt/branch_hints.hpp:28:13: note: in expansion of macro ‘likely’
 inline bool likely(bool expr)
             ^
In file included from /home/nathan/src/supercollider/server/supernova/sc/../server/memory_pool.hpp:22:0,
                 from /home/nathan/src/supercollider/server/supernova/sc/../server/node_types.hpp:26,
                 from /home/nathan/src/supercollider/server/supernova/sc/../server/synth.hpp:27,
                 from /home/nathan/src/supercollider/server/supernova/sc/sc_synth.hpp:31,
                 from /home/nathan/src/supercollider/server/supernova/sc/sc_synth_definition.cpp:24:
/home/nathan/src/supercollider/server/supernova/sc/../server/../utilities/simple_pool.hpp: At global scope:
/home/nathan/src/supercollider/server/supernova/sc/../server/../utilities/simple_pool.hpp:125:61: warning: ‘assume_aligned’ attribute directive ignored [-Wattributes]
     void * MALLOC ASSUME_ALIGNED(32) malloc(std::size_t size)
                                                             ^
/home/nathan/src/supercollider/server/supernova/sc/../server/../utilities/simple_pool.hpp:131:72: warning: ‘assume_aligned’ attribute directive ignored [-Wattributes]
     void * MALLOC ASSUME_ALIGNED(32) realloc(void * p, std::size_t size)
                                                                        ^
make[2]: *** [server/supernova/CMakeFiles/libsupernova.dir/sc/sc_synth_definition.cpp.o] Error 1
make[1]: *** [server/supernova/CMakeFiles/libsupernova.dir/all] Error 2
make: *** [all] Error 2

The text was updated successfully, but these errors were encountered:

danstowell · 2016-01-16T00:58:49Z

Hi - could you say what version ubuntu you are referring to please? "32 bit" isn't descriptive enough to reproduce an error. In case you're unsure, lsb_release -a tells you the details of your system, and gcc --version would probably be useful. Thanks

nhthn · 2016-01-16T00:59:46Z

Thanks for the reply. I am running Ubuntu Studio 14.04.3 LTS with gcc 4.8.4-2ubuntu1~14.04.

timblechmann · 2016-01-16T09:44:27Z

smells like bfd1d57.

@telephon, a commit message like "subproject commit" tells nothing about the intention.

furthermore, i don't understand why anyone directly commits to master, especially as you guys now have travis to compile pull requests before a merge. note that i had suggested for many years to always go through pull requests and get someone's review before something is integrated.

danstowell · 2016-01-16T10:33:26Z

Let's spell this out so that no-one has to dig around: it looks like @telephon has reverted the nova dependencies to older versions, and it's extremely likely this was a mistake. The weirdest thing is that this is an entire commit of its own, it wasn't accidentally committed while adding some other change.

Tim you make a good point that we now have travis available to double-check things for us, this seems very obviously a mistake when I inspect it, but it should really have been caught.

Anyway bfd1d57 must presumably need reverting?

…ies (Fixes supercollider#1794) This reverts commit bfd1d57.

LFSaw · 2016-01-16T11:53:27Z

I think to prevent such issues, it is important to have an agreed git-workflow written down somewhere.
The git-cheat-sheet has something like that. However, it seems to be outdated (and quite hidden...). I am happy to contribute by formatting and rephrasing but will certainly need advice (which in turn will make me learn how to do things). Anyone wants to help out?

telephon · 2016-01-16T11:58:42Z

@telephon, a commit message like "subproject commit" tells nothing about the intention.

It was a mistake, sorry. I never did anything to that file, and didn't write that commit message

telephon · 2016-01-16T12:04:05Z

furthermore, i don't understand why anyone directly commits to master, especially as you guys now have travis to compile pull requests before a merge.

I assumed that travis cannot check pull requests from another repo (there was a discussion here, I don't remember where it was).

danstowell · 2016-01-16T12:11:02Z

@telephon indeed, I hadn't noticed either, that travis can tell us if PRs from other repos are building successfully, rather handy!

timblechmann · 2016-01-16T12:21:26Z

there are plenty of git tutorials out there, i'm not sure if it is a good idea to write yet another one.
especially: once you understand the concepts of git (which are not rocket-science), you can always look up the git commands in the documentation. it is not about remembering 250 commands with 500 parameters, but understanding a few concepts.

going through pull requests has several advantages:

self-review (do i really want to commit this).
review (get a "lgtm" from someone else). people having commit access, can always merge their own code, if nobody else reviews their code.
travis-ci builds (does my commit actually compile?). it doesn't matter where the PR is coming from, it matters where it goes to (e.g. after resigning as maintainer i dropped my permissions to write to the repos, my PRs still go through travis)

LFSaw · 2016-01-16T12:56:54Z

The reason I suggested a git-workflow for SuperCollider where

there is already one
there are plenty of different ways on how to use git. IMHO, we should (in very brief words) describe how the SC community prefers to have contributions. Possibly (and hopefully) with lots of links to the aforementioned tutorials on git usage.

Travis seems to be a cool feature that no-one should miss.

especially: once you understand the concepts of git (which are not rocket-science), you can always look up the git commands in the documentation.

well, I spent a considerate amount of time looking into git concepts and am still not sure how to properly handle my suggestions and how to maintain my own fork so that PRs do not get outdated.
I am again suggesting therefore a simple list of how to contribute to sc. Something like

initial (once)

0a. Have a github account
0b. fork supercollider

feature development / bug-fixing

align your repository to the latest HEAD on master (how to do that?)
create branch with reasonable name (naming scheme?)
work work work inside branch
test test test inside branch
commit locally
commit to remote (personal) fork
create PR (how?)
wait for travis
fix emerging issues (raised from both, travis and other devs)
- where? in my forked repository? how to reflect possible contributions from other dev's?
wait for approval, negative: goto 9. else
merge happens (via someone else)

and then? Do I forget the branch I worked on? Do I "reset" my fork to the master HEAD? How?

these are the question I have from the top of my head.
And, when it comes to naming schemes, forking/branching/merging, I imagine there are very different ideas around the git userbase, so we should somehow clarify how this ideally works.

On 16. Jan 2016, at 13:21, Tim Blechmann notifications@github.com wrote:

there are plenty of git tutorials out there, i'm not sure if it is a good idea to write yet another one.
especially: once you understand the concepts of git (which are not rocket-science), you can always look up the git commands in the documentation. it is not about remembering 250 commands with 500 parameters, but understanding a few concepts.

going through pull requests has several advantages:

• self-review (do i really want to commit this).
• review (get a "lgtm" from someone else). people having commit access, can always merge their own code, if nobody else reviews their code.
• travis-ci builds (does my commit actually compile?). it doesn't matter where the PR is coming from, it matters where it goes to (e.g. after resigning as maintainer i dropped my permissions to write to the repos, my PRs still go through travis)
—
Reply to this email directly or view it on GitHub.

gusano · 2016-01-16T13:12:39Z

I am again suggesting therefore a simple list of how to contribute to sc

@LFSaw Could you please open a new issue (or submit a PR) about adding another git tutorial?

jamshark70 · 2016-01-16T13:14:34Z

align your repository to the latest HEAD on master (how to do that?)

First you need to add a remote reference pointing to the main SC repository: git remote add upstream whatever_the_URL_is_too_lazy_to_look_it_up_now. Then, when you need to sync:

git fetch upstream
git checkout master
git merge upstream/master

Note that I didn't figure this out on my own. Github's help pages on forking are very well done.

create PR (how?)

Github website. Visit the main SC repository and it will tell you that you recently pushed a branch, and ask if you want to make a PR.

where? in my forked repository? how to reflect possible contributions from other dev's?

Yes, updates have to go into the branch that is the source of the PR. If you pushed the branch into your fork, then updates have to go there too. You'd have to give other devs write access, or use patch files from git format-patch.

(Sorry to go further off topic. I wrote the above before gusano's message came in.)

timblechmann · 2016-01-16T13:29:15Z

 1. align your repository to the latest HEAD on master (how to do that?)

"github align your repository to the latest HEAD on master"
first google hit:
https://stackoverflow.com/questions/7244321/how-to-update-a-github-forked-repository

 1. create PR (how?)

"github how to create pull request"
first google hit:
https://help.github.com/articles/creating-a-pull-request/

jamshark70 · 2016-01-16T13:47:45Z

Having witnessed contributors get yelled at for doing the wrong thing with git, I can't blame anyone for asking which of the n ways of managing branches etc are preferred for SC.

timblechmann · 2016-01-16T14:05:40Z

my point is: almost none of these questions are SC specific. most of them are github specific. and github has plenty of documentation, which is probably better written than anything that the SC community can come up with.

LFSaw · 2016-01-16T16:42:39Z

I am again suggesting therefore a simple list of how to contribute to sc

@LFSaw Could you please open a new issue (or submit a PR) about adding another git tutorial?

@gusano I intended to do so, given there is sufficient resonance on the topic within the community. (It appeared to me that opening issues sometimes results in discussion being stalled or happening in parallel at two points).

So voila, here it is: #1796

While at it I'd like to mention that I am trying hard (and almost succeed) to not take your comment personal. I kindly ask everyone (especially in this community) to keep on being nice to each other.
Although, sometimes people appear to do things seemingly wring, they most of the time have reasons for doing so. Such a reason might also include "to have a different idea about contributing".
I am quite confident that being nice and either just let things happen or correct in a constructive manner (e.g. by creating an issue if you think it is needed instead of blaming others to not having done so) will eventually pay off by having people around that do care for SuperCollider and its development.
That said, I am also guessing that I overreact and things might not be meant the way they sound through written words in issue trackers. Peace! :)

danstowell referenced this issue Jan 16, 2016

subproject commit

bfd1d57

danstowell added a commit to danstowell/supercollider that referenced this issue Jan 16, 2016

Revert "subproject commit" which mistakenly downgraded nova dependenc…

38b69e6

…ies (Fixes supercollider#1794) This reverts commit bfd1d57.

danstowell mentioned this issue Jan 16, 2016

Revert "subproject commit" which mistakenly downgraded nova dependencies #1795

Merged

telephon closed this as completed in #1795 Jan 16, 2016

LFSaw mentioned this issue Jan 16, 2016

write down an agreed git-workflow for SuperCollider development #1796

Closed

crucialfelix added bug Issues that relate to unexpected/unwanted behavior. Don't use for PRs. comp: supernova labels Jan 17, 2016

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

supernova compilation error #1794

supernova compilation error #1794

nhthn commented Jan 16, 2016

danstowell commented Jan 16, 2016

nhthn commented Jan 16, 2016

timblechmann commented Jan 16, 2016

danstowell commented Jan 16, 2016

LFSaw commented Jan 16, 2016

telephon commented Jan 16, 2016

telephon commented Jan 16, 2016

danstowell commented Jan 16, 2016

timblechmann commented Jan 16, 2016

LFSaw commented Jan 16, 2016

gusano commented Jan 16, 2016

jamshark70 commented Jan 16, 2016

timblechmann commented Jan 16, 2016

jamshark70 commented Jan 16, 2016

timblechmann commented Jan 16, 2016

LFSaw commented Jan 16, 2016

supernova compilation error #1794

supernova compilation error #1794

Comments

nhthn commented Jan 16, 2016

danstowell commented Jan 16, 2016

nhthn commented Jan 16, 2016

timblechmann commented Jan 16, 2016

danstowell commented Jan 16, 2016

LFSaw commented Jan 16, 2016

telephon commented Jan 16, 2016

telephon commented Jan 16, 2016

danstowell commented Jan 16, 2016

timblechmann commented Jan 16, 2016

LFSaw commented Jan 16, 2016

initial (once)

feature development / bug-fixing

gusano commented Jan 16, 2016

jamshark70 commented Jan 16, 2016

timblechmann commented Jan 16, 2016

jamshark70 commented Jan 16, 2016

timblechmann commented Jan 16, 2016

LFSaw commented Jan 16, 2016