You forgot to replace SEC_IN_USEC ?

Well actually there are several errors... Can you try to fix them so I can rebase #6394 on top of this one? Or you prefer to first merge #6394 and then you add it to this PR?

@kYc0o, I don't think both PR will conflict. If you use the right convention in #6394 it will be fine.

The best is to wait for the first one being merged, the other PR will have to update accordingly.

I was a bit sloppy - as you can see from the commands pasted above. Should be fixed now by using the proper arguments for grep and adding a 'g' flag for sed.

ccn-lite needs an update

I used:

git grep -l SEC_IN_USEC | xargs sed -i 's/MIN_IN_SEC/SEC_PER_MIN/'
git grep -l SEC_IN_USEC | xargs sed -i 's/SEC_IN_CS/CS_PER_SEC/'
git grep -l SEC_IN_USEC | xargs sed -i 's/SEC_IN_MS/MS_PER_SEC/'
git grep -l SEC_IN_USEC | xargs sed -i 's/SEC_IN_MS/MS_PER_SEC/'
git grep -l SEC_IN_USEC | xargs sed -i 's/MS_IN_USEC/USEC_PER_MS/'
git grep -l SEC_IN_USEC | xargs sed -i 's/USEC_IN_NS/NS_PER_USEC/'

Wouldn't

git grep -l MIN_IN_SEC | xargs sed -i 's/MIN_IN_SEC/SEC_PER_MIN/'
git grep -l SEC_IN_CS | xargs sed -i 's/SEC_IN_CS/CS_PER_SEC/'
git grep -l SEC_IN_MS | xargs sed -i 's/SEC_IN_MS/MS_PER_SEC/'
git grep -l MS_IN_USEC | xargs sed -i 's/MS_IN_USEC/USEC_PER_MS/'
git grep -l USEC_IN_NS | xargs sed -i 's/USEC_IN_NS/NS_PER_USEC/'

make much more sense?

see #6399 (comment)

Sorry :-/

But as the discussion does not provide a consensus in #4211: what about CS -> CSEC, MS -> MSEC, NS -> NSEC?

I have no strong opinion, can do, if you prefer.

I prefer it, but you 1 and @BytesGalore 2 (quoting SI units) disagreed in #4211, with no reply to my argument why I still prefer it 3 (e.g. US_PER_S looks weird).

Actually, I interpreted #4211 as a consensus.

On the _PER_ part, yes. But the discussion thread seems a little bit more ambiguous about the S/SEC discussion to me (later posts liking the _PER_ only mention USEC_PER_SEC, the units of which are already SEC).

Which I read as an agreement on this solution. The only one who voted for SI units was @BytesGalore who kept silent during the later discussion with can be interpreted as agreement.

How about we make a quick poll tonight?

For the record, I would prefer SEC for seconds and MS, NS, US and CS for the rest - even if it is not 100% consistent.

How about we make a quick poll tonight?

👍

For the record, I would prefer SEC for seconds and MS, NS, US and CS for the rest - even if it is not 100% consistent.

👍

For the record, I would prefer SEC for seconds and MS, NS, US and CS for the rest - even if it is not 100% consistent.

We talked about it offline, and I agree now.

Updated accordingly.

Updated CCN-lite and removed patches. Ready to squash?

Jenkins says in https://riot-ci.inet.haw-hamburg.de/job/RIOT/job/PR-6399/9/artifact/error_airfy-beacon_linux_other_tests.log:

Building tests/xtimer_usleep for airfy-beacon
make: Entering directory '/opt/jenkins/workspace/RIOT_PR-6399-SI7A7I2QFQLIKR4ZMJNGNMT2GKJLP3TAHIUJWDXUDWBJZWO2Z3RA@2/tests/xtimer_usleep'
Building application "xtimer_usleep" for "airfy-beacon" with MCU "nrf51".

main.c: In function 'main':
main.c:37:28: error: 'SEC_IN_USEC' undeclared (first use in this function)
         xtimer_usleep(ONE_SEC_SLEEP);
                            ^
main.c:37:28: note: each undeclared identifier is reported only once for each function it appears in

Fixed the new test. Should I squash?

👍 squash please

squashed

needs rebase, now

rebased

requires merge of ccn-lite PR 104 and update ccn-lite pkg_version here, afterwards

cn-uofbasel/ccn-lite#104 was merged

I don't understand what cn-uofbasel/ccn-lite#104 has to do with this PR?

@OlegHahm nothing directly, but if you update the package version (which you have to do) and make you PR get through CI, you need the fixed ccn-lite version, that is with pr 104 merged.

see error log from jenkins here

Ah, I wasn't aware that cn-uofbasel/ccn-lite@d720a6c was already merged.

@OlegHahm: please update pkg version, so we get this and macOS support (#6341) into the release?

Updated