#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

#54

You can point them at your own fork via .gitmodules, just make sure those commits that change the URL never end up upstream on a monome repo. It’s not particularly bad, it just messes up the history a bit. The easiest way to do that (IMO), is to not change the URL as it’s only used for the initial clone / init (or git submodule sync).

#55

understood, no changes to .gitmodules allowed upstream. (so they are best avoided altogether if experience is any judge.)

sorry, i took the time to actually read the brain dump and it’s clearer now.

in a nutshell (i’m dense): add a second remote for interacting with my fork of the submodule.

#56

Definitely want an 80 char line limit?

@sam, sorry, i think i misunderstood - you would like a longer line limit, yeah? fine with me.

seems like if we’re gonna impose a format, now would be the time to do it. i’ll open a PR for libavr32 with clang-format and people can weight in on tweaks for it

[edit] … aaand, actually, i don’t know. it seems like clang-format just doesn’t handle aligning #defines. i can’t make it not do this:

-#define BANG        (0x1E)
-#define AT          (0x1F)
-#define POUND       (0x20)
-#define DOLLAR      (0x21)
-#define PERCENT     (0x22)
-#define CAP         (0x23)
-#define AND         (0x24)
-#define STAR        (0x25)
-#define OPENBKT     (0x26)
-#define CLOSEBKT    (0x27)
+#define BANG (0x1E)
+#define AT (0x1F)
+#define POUND (0x20)
+#define DOLLAR (0x21)
+#define PERCENT (0x22)
+#define CAP (0x23)
+#define AND (0x24)
+#define STAR (0x25)
+#define OPENBKT (0x26)
+#define CLOSEBKT (0x27)

anyone know a way around?
(SO doesn’t: http://stackoverflow.com/questions/27111078/can-clang-format-align-variable-or-macro-assignments-in-columns )

or, maybe i should be looking for a different formatter (uncrustify?); this is kind of a deal-breaker.

#57

Right, after banging my head repeatedly against a wall for 2 days trying to get avr32-toolchain to build properly on newer versions of Linux (there are issues with newer versions of gperf and texinfo), I gave up and just used the Atmel builds. Maybe when I stop being quite so fed up with it, I’ll write it up as an issue on the repo.

Anyway, the main point being, I’ve now got travis-ci builds running, I’ve just created 2 so far, a simple one for the teletype repo: https://travis-ci.org/samdoshi/teletype

And a more complicated one for the libavr32 repo: https://travis-ci.org/samdoshi/libavr32

The libavr32 one will download the master branch of each of the firmwares, copy itself over and test to see if anything breaks. It could be useful for PRs.

The downside, particularly for the libavr32 repo, is that we’re using submodules, we don’t need each firmware to work with the latest libavr32. There’s no point using a CI if you don’t expect it to always pass. IMO having a CI that is expected to fail is worse than no CI.

Anyway, let me know if you’re interested in getting travis-ci working on the repos and I’ll create some PRs. We’ll need to move this repo over to the monome org too.

Teletype refactoring ideas
#58

That brings back memories, sure enough I did run into that problem… from my post about aleph toolchain hosts way back when:

#59

There is this fork of the avr32-toolchain repo: https://github.com/lis-epfl/avr32-toolchain

They’ve got patches to fix gperf and textinfo changes, they build on my mac, (and bizarrely give some extra warnings when compiling our code). But I couldn’t get them to build on the travis-ci OSX images.

I’ll try to update the readme later this week with updated Linux recommendations.

#60

for what it’s worth, i’ve never had much luck with the jsnyder toolchain scripts on linux, nor had much motivation to try very hard since the atmel releases work fine.

the whole strategy of the Makefile seems kinda… brittle. combining specific arbitrary versions of gcc boostrap sources, with basically random versions of tools like texinfo…