#41

aleph only…

#42

aleph, trilogy, and tt here.

Apologies for being MIA in the discussion, time has been really scarce of late. I have some small fixes and additions to the usb midi host support that came from my earthsea hacking which I still need to back port to aleph - having a more common code base would certainly make that easier!

With the effort to craft a common core code base I was wondering how people felt regarding something like a test suite? I ask because making changes to the common core that don’t cause accidental regressions may get more difficult if people don’t have all the devices to test against.

Thoughts?

1 Like
#43

Before I bought my ES, I’d seen your midi branch on GitHub and it definitely influenced my purchase. There is a PR to merge skeleton into system, and then hopefully try to merge that with avr32_lib in the aleph codebase.

A test suite would be amazing, particularly as you say, not all of us have all the devices. Can we find something that will let us run tests on hardware as well as on the computer? I think a lot of the code is device and IO specific (i.e. USB hosts, interrupts, DACs, etc), I’m not really sure how you’d deal with that. Even if we can’t test that, it would be good to make sure that ‘interfaces and behaviours’ don’t get changed accidentally.

#44

Little self-test app common to all hardware sounds like it could be a fun project. Fast-forward to a time when we have now merged system/skeleton into avr32_lib. Then when avr32_lib changed to add a feature intended for one device, join forces to recompile & fire up the self-test app on all devices before merging pull request…

Referring back to the checklist on github issue:

I think we’re at a point on that checklist to:

  • build, for example, a statically-routed standalone app built from the modified grid & life ops on my feature branch which simply runs op_life on a 16x8 grid - tick time around 1/2 a second, button presses toggle cell contents.

  • create another build target in the life app makefile targetting teletype hardware (still from aleph repo), pulling in whatever files are required from a checkout of system/skeleton in order to get a working build

  • merge whatever needs to be pulled in straight to avr32_lib

I’m still running along on kind of a huge assumption we can use bees bangs to abstract away every single button press & LED change. Thoughts? Performance worries!?

#45

@sam: posted some comments on the PR. thank you again for doing it! exciting to see it coming together.

@ngwese: having a test suite would be great, but not sure how it would work in practice… emulating the hardware somehow?

#46

Regarding a test suite… mocking the hardware seems rather ambitious and is admittedly more than I could commit to working on right now. I just looked through the skeleton/system code - a much greater percentage of it is tied to hardware / hardware APIs than I remembered.

When I first thought test suite I was imagining there there was more code in skeleton/system like this notes.c file from the midi earthsea mod:

…that code just implements a data structure which is largely independent of any hardware making it easier to test.

On a separate topic I was also wondering if it would be worthwhile to have each module’s config.mk file define a preprocessor symbol like say -Dplatform=earthsea or -Dplatform=aleph so that code in the core could be specialized to the target hardware/platform.

Would board be better name than platform?

#47

Yes, having just gone through most of it to merge it, it’s very hardware specific. Maybe the aleph version which is much larger has a lot of non-hardware things in it?

I’ve been thinking about this too, I posted a tree diagram further up the thread of the various bits of hardware we have, having some #define statements to reflect this would be a good idea. I’m not going to do it for the system / skeleton merge, it’s probably better tackled when we merge back with avr32lib (from aleph).

Speaking of which, I should have the merge finished by tomorrow.

#48

platform #defines: maybe the most obvious place is in each project’s conf_board.h ?

Maybe the aleph version which is much larger has a lot of non-hardware things in it?

not really. aleph has a little more hardware to talk to, and i guess a little more boilerplate behavior that is baked into main.c. i guess some modules like monome and region are abstract and testable, but for the most part the lib is really meant for hardware-specific stuff, aleph app code is where all the hardware-agnostic functionality lives.

in aleph/utils/avr32_sim there is a copy of the library with all the poroblematic definitions somewhat messily stripped out, so at least it compiles without ASF and everything.

#49

Okay, system / skeleton merge is nearly complete, just adc left to sort out, comments regarding that are on the PR.

If it gets merged it will end up breaking any code from outside the repo (e.g. Orca and the MIDI input for earthsea), I’m happy to help get those working again. (The changes should be trivial.)

Now that that is nearly out of the way, I hope I can make a little constructive criticism…

1. Indentation

If you were to get forensic about the code, you can see it’s been written by 2 people with different text editor settings, @zebra (the original author) favours 2 space indentation, @tehn goes with tabs (and occasional 8 spaces). Lots of trailing spaces too. This makes my 2 text editors light up will all sorts of warnings. Even GCC will be getting in the act soon. Messed up indentation leads to serious bugs. It also makes doing diffs a pain (and I know should know!)

Can we standardise on one set please. Perhaps we could add a .editorconfig to the repo. Maybe in the future we could go with a .clangformat. As an aside what text editor is everyone using?

Please don’t go and change all the formatting now though, as it will lead to problems with…

2. Git blame

If you’ve never used it, the git blame command (or on GitHub) is really useful for tracking down why changes were made, but it works best if people make smaller commits (with sensible commit messages). Not everyone likes this style of using git, if you have a big project you can end up with a very large commit history, but I think for us it would be a good idea.

(rant over)

Are we ready to start thinking about merging skeleton and avr32_lib then?

I think we’ve got 3 options:

  1. A new repo for the newlib, but with no tracked link to the projects using it. e.g.
cd ~/Projects/mod/teletype
export NEWLIB_HOME=~/Projects/newlib
make

  1. A new repo for newlib, but linked in using either submodules or subtrees.

  2. One giant repo with both the aleph and the modular source code (and maybe Orca if @scanner_darkly wants to).

If we do decide to chop things up into a few interlinked repos, we might need a new GitHub org, @tehn had mentioned moving the aleph repo to the monome org, but it might be a bit confusing having the modules in there as there are already meadowphysics and teletype repos.

#50

the latest changes make sense. should be straight forward to update orca accordingly. @tehn actually suggested moving orca into the mod repo, i think it probably makes sense to wait for your branch to be merged, then i can update orca and move it to mod.

agreed on indentation and smaller commits for shared stuff. i use notepad++ as my editor. no preference on the repo set up - good with whatever you guys decide!

@rick_monster - can’t comment on what you’re doing since i don’t know aleph / bees that well, but just wanted to mention i’m watching what you are doing with interest as i’m thinking of how grid could be integrated with teletype.

1 Like
#51

re: standard indentation

fine with me. i use emacs. it is easy enough to add a save hook to run clang-format and i think adding a .clangformat is a good idea. i’ve never used EditorConfig.

for the most part i’m not super picky about formatting, except for one thing: <rant> @tehn and @scanner_darkly both omit curly braces on if statements; i strongly consider this a bad idea and will unapologetically add the braces when i see it. the omitted braces are an excellent source of bugs in c/c++ - including, in a way, the Apple example linked above. (well that and goto, which of course we don’t use…) </rant>

i’d also much prefer spaces to tabs, but not a big deal.

re: git blame, small commits

makes sense to me. i will try to be more disciplined, it was pretty sloppy for a while there.

i’ve seen the exact opposite philosophy too: that each PR should be rebased to a small number of commits, each encompassing a complete feature or fix. i can see the benefit to that too; it’s easier to review a smaller number of diffs.

re: repo structure

if possible it seems like it would be cleanest to add newlib or whatever as a submodule to the aleph repo, replacing aleph/avr32_lib, rather than bunging all the aleph code into the modular repo? (alephs are more rare, after all.) unless maybe it does actually prove useful to use operator code in modular firmware? really i am not sure. would like to keep the aleph issue history if possible.

#52

Emacs user with a preference for spaces here. I definitely struggled to prevent generating whitespace only changes to files early on.

The .clangformat suggestion sounds good to me as well (I didn’t realize it existed). I do love consistent formatting regardless of style. I’ve generally tried to mimic the prevailing style within the code base but there have been times when I wasn’t sure what the right call was.

On the git usage style front I’m probably in the middle ground. I agree with @scanner_darkly that shared code generally benefits from smaller succinct commits with clear messages. That said I also tend to be a heavy user of rebase to squash down potentially myriad commits into a handful of succinct commits which could easily stand on there own. I try to save people from having to wade through my thought process along the path to my ultimate destination.

#53

thanks for tackling this refactoring - excited and very grateful that we will get some new goodies into aleph!

hearing the concerns on style/formatting & enforcing 2-space convention (or whatever) sounds fine to me as emacs user. Also sorry for any insane commit messages in aleph and/or if-without-curly-braces! Hopefully nothing bonkers bleeding out into avr32_lib I did try to take care quarantining hacky/experimental stuff.

‘newlib’ as submodule sounds right to me. For bfin dev on aleph we also have a dsp directory to handle code reuse between modules. I tentatively suggest that ‘newlib’ can be split into ‘OS’ part (common to all aleph/system apps) & ‘control-blocks’ part which would contain such things as a ‘white-whale’ or a ‘life’ which can then be included as part of any app, including bees.

The challenge for each ‘control-block’ is to break out the interface to hardware/bees-bangs cleanly in control-block header. Likewise for any features which are standalone-only. These interfaces can be tailored to each ‘control-block’ in it’s .h file, whereas implementation of the missing functions is left to the app.

Forcing every app to conform to bees’ everything-is-s16 for, e.g all grid interaction, makes little sense to me now…

#54

Seeing as we’re 4 out of 5 emacs users… editorconfig and clang-format. I think it would be best to go with 2 spaces indentation (no tabs), as a lot of the code is already using that, and it’s seems perverse to introduce a third format. At some point we can bite the bullet and reformat all the code with clangformat too.

Regarding commit size, for the PR I used lots of small commits to make it easy for myself and others to follow along, but I’m happy to squash and force push before the final merge (that’s probably my preferred way of working these things), however that only really works if everyone’s got time to review the code and test on hardware first, otherwise I’d rather keep the smaller commits to make debugging and bisecting easier.

If we did end up with a single repo, I’d push for the modular code being merged into the aleph repo, a lot of binary cruft ended up in the mod repo (the .git dir is 100meg). I can see scenarios whereby having a single repo would be advantageous, it really depends on how much of bees ends up in the modular code.

At the moment I like @rick_monster’s plan best, having some highly abstracted ‘control-blocks’ (or macro-ops?) that aren’t dependent on anything but some interfaces. We could then create a wrapper for each control-block for all our platforms, aleph, modular, simulator (and maybe even the Max C api).

I think we need to decide what solution we want before we start splitting code up, and someone will have to volunteer to knock up a proof of concept. Also we should probably wait for @tehn to get back from his travels…

#55

honestly i don’t have strong opinions on many of these matters-- my inclination is towards maximal collaboration, and several of you are much more versed in best practice to achieve these goals.

apologies for the tab/space issue. i’m using sublime, but have been meaning to learn emacs forever. sublime certainly has some tab/space conversion settings that i’ll investigate.

there are of course some much larger issues re modular apps on aleph-- i’m away for one more week, and road trip driving isn’t good for focussed productivity. i’m not suggesting specifically that you all need to hold up for my approval-- my main concern is that existing apps continue to work for our user base (which is a pretty low bar).

#56

re: coding style

i also prefer spaces over tabs (haven’t been doing it though), but prefer 4 spaces instead of 2… and actually i agree on omitting curly braces! but i think if the whole statement is one line that can be an exception.

regardless of personal preferences my general rule when working with somebody else’s code is to adapt their style anyway (including naming conventions), so i’m good with whatever we agree on. this will only apply to shared code anyway, so makes sense to keep it consistent.

re: git

i don’t have strong preferences here, and i don’t have much experience with git, but based on my day job i do prefer doing code reviews on smaller check-ins, and i find it provides for better discussion then one massive change… but other than that i am good with whatever you guys decide!

#57

… and Finally got my emacs setup just right

#58

[quote=“tehn, post:55, topic:2475”]
my main concern is that existing apps continue to work for our user base
[/quote] to me…potential improvements and innovation for this platform outweigh concern over compatability

it’s a bit like the wild west already so if there’s a chance for more adventure i say go for it

#59

I very much agree with @glia here: who’s going to complain if Bees gets better in basically every way?? Also, every single scene I have made so far was first drawn on paper, so I’ll reprogram them and that’ll be just fine.

#60

I’m working on arbitrary op deletion today - shouldn’t speak too soon but last compile-flash cycle looked promising! (… bffff that’ll teach me to speak too soon)