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

#61

@glia, @Yann_Coppier would you guys be able to help out testing arbitrary op deletion feature?

Umm basically this task doesn’t require any programming but does require a working avr32 toolchain setup to compile and help. The feature added here was kind of scary to implement (bit of a brain-melter, nearly drove me nuts several times today)

If other people can help test the snot out of it and see if it behaves well off the test-bench I would really appreciate that! Especially valuable information would be any reproducible crashing or scene-corruption bug but general indication of stability would help us give this change a cautious thumbs up…

(sorry for the thread hijack I guess this is a little off topic…)

1 Like
#62

Sure. So I just have to take the 3 modified files, recompile and try some old + build some new scenes, right? Very doable, very soon. Expect some news from me about that, and looking very much forward!

#63

I think this is done now, it needs testing and reviewing. If you do want to review the changes you might find it easier to review each commit. I’ve had a quick play on my teletype and earthsea, no problems so far. I’ll load it up on meadowphysics later, but I don’t have a whitewale, so can’t test that (or kria).

#64

The best would be if you can test against the entire branch I’m pull-requesting, rather than just those 3 files. helps to nail down what’s going on if there is a bug. Feel free to PM me if you need a hand with the requisite git spells or any other basic questions…

#65

posted a comment on the PR. i can help with testing white whale (and will test orca once i get around to moving my repo).

#68

Yes. First test and there is a bug for sure. Deleting the operators works fine, but for instance with this simple task:

ENC/VAL -> ADD/A
ADD/SUM -> SCREEN/FILL

With ENC/MAX=10 and ADD/B=5, I can modify the screen shade from 5 to 15.
Now if I remove the operator ADD, in between PRESET and SCREEN, everything seems to work fine until I press the Mode Switch to go into performance mode. Then and only then my Aleph freezes and I have to remove the power plug. I tried some other configurations, same issue each time so far.

Aleph Testers Corner
#69

let me just say that while much of this thread is over my head, following along and seeing the effort put forth by this community is very inspiring.

2 Likes
#70

The system and skeleton merge PR has been merged. If anyone needs any help porting or rebasing code, let me know.

1 Like
#71

will try to update orca accordingly and move it to the main repo within the next couple of weeks.

1 Like
#72

did have a quick try compiling stuff from mod against avr32_lib couple of weeks ago but somehow couldn’t get a grip on it.

Attempting to add a couple of bees features I wanted unexpectedly turned into an enormous refactor so now I’m too far into that to turn back. Hopefully it actually bears some fruit in the next week or two then I can think about whether to look at this merge again or more blackfin dev…

#73

Is that definitely the plan? Or are we going to split the mod repo into separate pieces, each with a submodule for the skeleton folder?

#74

i’d prefer to split the repos with a skeleton submodule. i’ll need to read up (or some assistance) on the submodule setup.