#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…

#61

It’s handy because it does build a usable toolchain on OSX, which is very convenient. But I agree the Makefile is really hard to deal with. When it stops working I’ll replace it with the Atmel binaries and Vagrant / Docker / whatever the flavour of the month is.

@tehn, any interest in the getting travis set up?

https://travis-ci.org/samdoshi/libavr32/builds/118831379

#62

at this point i’m still coming to grips with the submodule workflow-- minor confusion being worked out right now in fact while adding clock division to MP (which requires abstracting the external clock, which is a good thing in general).

i’ll check out travis!

#63

I need to get the teletype codebase cleaned up a bit before I work on it, I’m going slightly crazy trying to follow control flow with the mixed up indentation.

So I was thinking, it doesn’t have to be a continuous affair, we could just take the hit once, sort the #defines out, and then all just try hard to keep it tidy looking. Thoughts?

@tehn, shall I just get on with it and run clang-format against the teletype codebase?

#64

i say go. i can help sort out the messy things by hand as well (ie #defines)-- i’m pretty fast with sublime hotkeys

#65

Works for me … 20

#66

Is wrapping #defines in // clang-format off and // clang-format on an option? (Does that even work?)

EDIT: more on clang ignores in the docs.

#67

Yeah, that occurred to me, it is a little irritating to have to baby the formatter that way. Good point though; probably better than having to fix things by hand.

#68
#69

Late to the party but yes please!

#70

working with teletype code right now and the 80 column clang format is driving me a bit crazy - any opposition to changing it to 100? or even 110/120?

#71

i could be ok with 100, though i understand the style guideline for 80.

what editor do you use, by the way?

(i’ll generally defer to @sam on these matters)

#72

No opposition from me on switching to 100 columns.