#34

ok cool, but will still work via fork/PR and wait for sam to force-push libavr32 - since i don’t fully grok the process with the scripts and everything.

#35

@tehn you might want to decide how to manage the permissions for the monome organization.

According to this page:

There seems to be a mixture of true owners, “owners” by way of an owners team, and then a few which can’t do anything :slight_smile:. I discovered this when I went to assign the earthsea midi issue I opened to myself and couldn’t.

IIRC in Github if you are an “owner” then you will inherit full control over any repo placed under the monome organization (which may be what you want, maybe not). The structure I have in place at work has most people in a team with full push/pull rights and I add that team to the various repositories as needed.

@sam congrats for pulling all this together. I’m anxious to get going with the new repo structure - it will be a lot nicer than having ideas/experiments hanging off in random branches! Thanks for making it happen.

#36

it’s true, things are confusing. github’s access management changed and i skimmed the changes without fully considering what was new.

i just changed default “member” access to have read/write access. “owners” now only additionally gains access to add new collaborators.

thanks for the heads up. (i mean, i hope i got this right now)

#37

just catching up - another big thank you to @sam for all this incredible work!

and i’m starting to think that using submodules makes a lot of sense. breaking changes should be rare, and any developer that still actively works on their firmware will likely participate in PR discussions, and firmware that is not actively developed anymore can remain working. also seems like this should help avoiding merging aleph and modular repos.

so i think this will also make sense for orca, i’ll wait until the changes are pushed and will update my repo and add libavr32 as a submodule. this will make it easier for anybody wanting to make mods to it as well as they won’t have to separately clone mod.

once the reorganization is done what should be the process for making changes to libavr32? fork or maybe simply use branches? i assume it should be possible to point a submodule to a different branch as it’s just another commit?

#38

I’m going to push the code onto the monome org repos this afternoon (UK time), once I’m back from lunch.

After that my todo list is as follows:

Sounds like a new submodule tutorial would be most useful, I feel like I’m starting to get a good handle on them and what a good workflow should look like.

I also think that if we want to reformat the code, now is the time, before everyone has forked, and making such sweeping changes would cause rebase hell for everyone. Anyone want to volunteer to setup a .clang-format for us to use?

#39

I think so, you could have a think about the best way to share code between the different hardware we have, I posted this elsewhere, but we have the follow tree stucture

  • aleph
  • modular
    • trilogy
      • whitewhale
      • earthsea
      • meadowphysics
    • teletype

When I did the system / skeleton merge, I just did something that worked. If you want to put some effort into a proper way of handling it that would be fab.

I’d been thinking about ways to share code, starting with something new is probably the best way to explore ideas and once it works well port the existing firmwares over. I’d been thinking along the lines of having a common header to define our hardware independent functions (e.g. set_monome_x_y, set_display_x_y, HAS_DISPLAY, etc), then each target can provide it’s own implementation for those functions. I think this is pretty similar to what @rick_monster proposed. We could start a new thread to discuss it?

Module / aleph code sharing
#40

Done.

Can I create monome/diet-asf for this to live at?

#41

fantastic. this is a monumental step forward.

certainly!

i’ll be researching this later tonight-- though i suppose it’s more of a consensus situation. i don’t have terribly strong feelings and would be happy to conform to agreed upon style standards.

#42

@tehn, @sam - this is a bit of an aside but I was wondering if it made sense to move the (functioning) avr32-toolchain repo into the monome organization as well?

2 Likes
#43

I think that’s a really good idea, it had been at the back of my mind too.

For me, that repo was the first thing I had to do to get started with firmware dev, if I recall I had to tweak a URL to get it compile. It would be nice to get a travis-ci script in there to make sure it’s always working.

#44

agreed, you should have perms for this. let me know if anything is up.

#45

Okay the avr32-toolchain is now under the monome organization. I’ve reforked it so that anyone who was looking at my repo should still work.

This development page on the main monome.org site should be updated to point to the right place.

#46

Anyone want to volunteer to setup a .clang-format1 for us to use?

i could do that. don’t have strong opinions on formatting per se (some opinions on style, but that’s different)

i’m the one who has been using 2-space ‘gnu’ style in the sources. it’s the emacs default and i’m used to it. (this actually specifies a weird extra indent level when you have an opening brace on a new line, but i never do that in C for whatever reason.)

maybe k&r or Google would be more “neutral.”

is 2 spaces ok? i like keeping lines short for working with multiple columns. but maybe 4 is a better compromise.

#47

done, thank you for moving over the repo.

k&r 4 space is my vote, though it’s not a strong insistence by any means.

#48

i didn’t see a builtin clang style for k&r, so used google as a base instead - similar enough i think, very widespread. using 4 spaces:
( https://github.com/catfact/aleph-old/blob/dev/.clang-format )

made some edits to be more permissive of multiple statements on one line, and similar. feel free to change…

here’s what it aleph codebase looks like after applying it (skipping ASF and other 3rd-party code)

seems to be a clang-format limitation that it can’t do alignment on #defines. which makes a lot of hardware-related headers look terrible. lmk if you have a workaround…

#49

Definitely want an 80 char line limit? I’m not super fused, but I’d also be happy with 100.

Have the else on the same line as the closing and opening braces drives me nuts, but I guess that’s a C thing as I see it in lots of places. When in Rome…

#50

I’ve added the diet-asf repo.

And even made an issue for it…

@tehn, you can downgrade my membership of monome back to member now

#51

done, but i’ve changed member perms to have read/write, so you have authority to merge (i think, if i did it right)

#52

I was going to write some longer comments about submodules, and I can still do if needed. Instead I’ve got 2 links that might be helpful, the Git Book chaper on submodules, and this blog post which goes in to the internals a bit (it is quite old though). Now onto the brain dump…

They key thing to take away is that there is a difference between the source URL to the submodule and the stored commit hash of the submodule. The commit hash is stored in the Git history, it does not care what the source URL is. Git is distributed after all!

The URL is stored in the .gitmodules file, and should always be https://github.com/monome/libavr32.git unless you know what you are doing. Don’t commit a change that modifies that. The URL in .gitmodules is just the initial checkout URL. If you want to change the origin URL for the submodule for a local copy just:

cd libavr32
git remote set-url origin git@github.com:samdoshi/libavr32.git
# also a good idea to set an upstream remote
git remote add upstream git@github.com:monome/libavr32.git

Now you can push, pull and fetch to your own GitHub account. (There are other ways to do this too… I think.) To revert to the .gitmodules URL, do a git submodule sync.

If you want to update the commit that the parent repo points to, change the checked out version of libavr32 and commit the libavr32 directory, e.g. to update it to upstream/master (this is assuming that libavr32 is clean and that you haven’t made any commits to it).

cd libavr32
git checkout master # checkout local master branch
git fetch upstream
git rebase upstream/master # rebase local master onto upstream/master
cd ..
git add libavr32
git commit -m "updated libavr32 to master"
git push # now go to GitHub and open a PR

You could also cheat and do it using a detached commit

cd libavr32
git fetch upstream
git checkout upstream/master
cd ..
git add libavr32
git commit -m "updated libavr32 to master"
git push # now go to GitHub and open a PR

When you git pull or git checkout, your submodule won’t update! You need to use the git submodule update command, beware if your submodule is dirty (see the --merge and --rebase options). You’ll find that your life is a lot easier if you don’t work on the master branch.

One final tip:

git config --global status.submoduleSummary true

will change your git status command to show submodule info too.

1 Like
#53

Definitely want an 80 char line limit?

pretty sure this is that:
( https://github.com/catfact/aleph-old/blob/dev/.clang-format#L25 )

re: submodules

The URL is stored in the .gitmodules file, and should always be https://github.com/monome/libavr32.git unless you know what you are doing.

so it’s not a good idea to have my forks of module repos point at my fork of libavr32? given that i’m probably going to have PRs for libavr32.
just curious