Build broken in 'dev' branch

[krasin]

Travis CI run failed with the following error:

avr-gcc  -mmcu=atxmega192a3 -gdwarf-2 -std=gnu99 -Wall         -DF_CPU=32000000UL -Os -funsigned-char -funsigned-bitfields -fpack-struct -fshort-enums -MD -MP -MT plan_line.o -MF dep/plan_line.o.d  -c  ../plan_line.c
../plan_line.c: In function ‘mp_aline’:
../plan_line.c:127:3: warning: implicit declaration of function ‘mp_unget_write_buffer’
../plan_line.c: In function ‘_test_anneal_block’:
../plan_line.c:388:56: error: subscripted value is neither array nor pointer
../plan_line.c:390:43: error: ‘mpMoveMasterSingleton_t’ has no member named ‘bqti’
../plan_line.c:392:2: error: expected ‘,’ or ‘;’ before ‘if’
../plan_line.c:390:8: warning: unused variable ‘c’
make: *** [plan_line.o] Error 1
The command "make" exited with 2.

The commit that broke the build is 45ea211f5f04a0cdf95ee1c583b7226a7a77139c

[krasin]

Hm... it seems that I incorrectly identified the breaker. It should be 6abf26e16ad52b949476d94ef01d2b47c6edf1da

[krasin]

I tried to fix it myself. There's three compile errors:

• a missing semicolon at line 390
• mm.bqti does not exist (probably, should be mm.anneal_bqti)
• bn->gm.units_mode is a scalar (uint8_t), but it's accessed as an array: bn->gm.units_mode[axis].

The third error is where I failed to find the fix, since I don't know what was the intention.

[aldenhart]

Builds will often be broken in the dev branch. Dev is my sandbox and there absolutely no guarantees about what's in there. Currently I'm working on some new functionality that does not yet compile. While I appreciate the help, best not to try to fix anything in dev, as this will just confuse things.

As things get more stable they are pushed to edge. There is an expectation that edge will function reasonably, but is still experimental and should not be used for production uses.

[krasin]

Hi Alden,

understood. Thanks for the explanation.

Quick question: what's the branch I should send my pull requests to? edge?

(non-obligatory background: I own an Othermill and am also building a small CNC machine with TinyG, so I do expect some amount of changes coming from me)

[aldenhart]

It's probably best to send to dev and that's what's active and we will find errors (mostly mine!) earlier that way, but be aware of what's in dev. I try to be explanatory in the commit messages. Anything labeled as interim commit or intermediate commit is probably bad. As long as you know you are getting raw code it's OK.

Also, dev goes through cycles. Sometimes its just simple bug fixes, sometimes it's new feature development, sometimes it a deep exploration of something arcane, and other times it's updating and tracking the to G2 code base. Depends on what needs to be done.

[aldenhart]

BTW - I've got 2 othermills here - and old one and a new one. I've been doing a lot of work on them. Amazing machine. What we really need now is some automated testing on the OMC.

[krasin]

It's probably best to send to dev

sounds good. I realize that dev is not a stable branch and that it's expected to be broken some of the time. I guess my tactics would be to wait for a "good weather" each time I want to send a pull request.

What we really need now is some automated testing on the OMC

My current wish is to try build a simulator for TinyG suitable for running automated tests against it. Ultimaker 2 Marlin firmware has a similar simulator, although, for manual tests: https://github.com/Ultimaker/Ultimaker2Marlin/tree/master/MarlinSimulator

Unfortunately, it would be hard to make a pure simulator, since none of the open source simulators can simulate Atmel XMega. For example, simulavr is limited to ATmega.

As for the automated tests on the real hardware, it's probably easier to implement (granted, it would be a bit flaky and will require manual interruptions from time to time), but they would always be more expensive to run, so I don't imagine running these tests against each commit or a pull request.

In the long run, both kinds of automated tests will be useful.