ah, i see, i think. so the asf goes into each libavr32 as a submodule. so a sub-sub-module of teletype for example.
i’m good with the second option as well. it makes more sense.
No, it’s just copied in. I’ll try to get functional copies up on my GitHub later this week which should hopefully make everything a lot more obvious!
that makes sense, absolutely. i’m way over-multitasking and my brain is jumping to conclusions today.
1 Like
i know (and hate) this feeling.
Ahem, drum roll please…
Also, staring in a supporting role walk.
I’ve very briefly tested meadowphysics and teletype on hardware.
These are just on my personal GitHub account while we test, I’ll (force) push them to the monome org once we’re happy with them. The whole process is automated, so if we want to make any other changes now is the time.
I’m considering renaming each of the project directories to src (e.g. in the teletype repo, there is a teletype folder, I’m suggesting renaming that to src).
The libavr32 submodule is linked via https rather ssh, this makes it more beginner (and anonymous user) friendly. It’s possible to change this to ssh in your own clone (as well as all sorts of other tricks).
The respective config.mk files have different path structures for the CSRCS and the INC_PATH variables, this was to stop the object files ending up in weird places. If anyone has a better idea, I’m all ears.
Beware, if I make any changes to these repos they will be force pushed.
Don’t forget to git clone --recursive to bring in the submodule
amazing!!
agreed!
will get to testing everything right away.
thank you immensely for sorting this out. it feels remarkably clean and sensible-- a great model for projects going forward.
happy to report that all hardware is working thoroughly as expected.
renaming to /src makes a lot of sense as to not see teletype/teletype folders.
i’ll also standardize the flash.sh scripts once this gets pushed to monome
spectacular work! i’m truly indebted. and your scripting skills have inspired me to think differently about some of my workflow.
I’m a big believer in reproducibility for this sort of stuff, and also of using git to give you a safety net. I just pushed the scripts I wrote up to a gist in case anyone wants to see them… there are some hardcoded paths in there, so it’ll only work on my computer. split.sh is the file that does the business.
The diet-asf repo is up too, it’s a bit abusive of git and GitHub, storing such a large file, but I don’t think it’s something that will be needed very often.
I’ll do the src rename soon too, either tonight or tomorrow morning.
2 Likes
Done. I’ve force pushed to repos.
excellent. what’s the process of pulling these into the monome github user? at the moment the repositories are blank with issues slotted in.
Assuming I have push rights to the repos on the monome org, I can change the username in the script I wrote and it should rebuild the repos (with the correct url for the libavr32 submodule) and force push them.
I’ll need to create the libavr32 and walk repos manually first too.
hello… sorry again for being quiet on this thread
@sam, huge kudos for the refactoring and reorganizing work!!
so… i am putting together a new aleph avr32 app (which could also be useful on teletype) and thought it would be a good step to try building it against libavr32. rather than getting into bees right away or something.
so, i guess at minimum i should fork libavr32 from monome (whenever its ready) and add libavr32/conf/aleph/conf_board.h, etc.
and then… statrt a separate repo for this app, i guess, adding submodule pulling from my libavr32 fork? (or from the upstream?)
and then… i guess decide where to put aleph HAL in the new scheme of things, and where to distinguish between TT and aleph builds.
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.
@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 
. 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.
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)
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?
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:
- a new submodule tutorial, particularly with respect to development workflow and forks.
- .editorconfig and clang-format
- travis-ci
- READMEs
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?
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
- trilogy
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?
Done.
- monome/libavr32
- monome/earthsea
- monome/kria
- monome/meadowphysics
- monome/teletype
- monome/walk
- monome/whitewhale
Can I create monome/diet-asf for this to live at?