Contribute / get into the code

[lerno]

If I'd like to contribute to the code, is there some area where one reasonably could do some minor cleanup / additions without having to understand the entire code and it's useful enough that you'd accept a pull req once it's done?

I noticed that there were two pull requests that wasn't accepted, if I spend some time doing additions I'd like to make sure it's somewhere helpful. So where could one start?

(BTW, the code is a bit inconsistent in its formatting, consider a style guide for the source)

[bas]

Always good to hear. Let me think about a good start topic..

[bas]

Maybe you can look at the operator precedence? That is C2-only (no LLVM/Clang).
Changing the precedence order from C does bring one nasty bit: C-code generation should take
this into account when generating C (ie add some extra parentheses)

Step1 would be changing Parser and looking at the resulting AST (c2c -a1). This step can be varified on its own)
Step 2 would be changing the C generation. Because the changes are not that big, maybe we can get away
by always adding parentheses around (new) order 4 and 5 (that were boosted up).

[lerno]

I'll have a look at it.

[lerno]

I ran into that (1 << 2) + 3 bug in the compiler and at first I thought I'd done something seriously wrong. Then – because I don't know the code so well, I had to spend quite some time narrowing down the problem. And finally fixing the bug, by that time you already fixed it from my bug report... 

Anyway, there's a pull req for updated precedence rules.

Because I wasn't sufficiently lazy I didn't find a way to just run a single test. It's probably dead easy, but please add that to the instructions somewhere because others might have the same problem.

Regarding cmake in the instructions for Mac, it's no longer necessary to get that from its own download. Using homebrew is fine.

[bas]

So the command would be 'homebrew cmake' ?

[lerno]

brew install cmake

[lerno]

Another thing, I'm used to making small, controlled changes when I work with existing code. I don't have much experience working in open source over github though.

Right now I have two pull requests filed and that's about as many as I like to keep "in the air" at the same time as the chance for more complex merges quickly increase.

On the other hand, writing something like defer (which touches several aspects of the code) might be difficult if it's split into multiple check-ins.

What is preferred? I don't know how long time it will take to get approval (or rejections) on pull requests either.

I will personally work in bursts, maybe claiming a few days to implement an entire feature, then spend the time on other things for a longer period of time. So it would be good if there could be some efficient workflow for that.

[bas]

You should keep the master branch of your archived synced with the official repository. For a feature, just
branch off and push it to your server. Ideally different pull requests are indepedent, so the order of merging
doesn't really matter. If a changes consists of several pull requests than it becomes a bit more hassle.

Solving merge issues is never fun, so avoiding them is better . So if you plan to do a big change, discussing
it upfront might save time.

[lerno]

Got it!