Re: [riot-devel] Travis Backlog

[TamGiang Tam]

Hello Martine,

IMHO, make all the test (unit tests, compile with set of mcus) should be
simple in localhost so that we can run it more frequently. Then how about
single make command for all equivalent travis tests?

Bests.

Vào Th 4, 2 thg 3, 2016 vào lúc 21:30 Martine Lenders <
authmille...@gmail.com> đã viết:

> Hi,
>
> do you mean
>
> BUILDTEST_MCU_GROUP=foobar ./dist/tools/travis-scripts/build_and_test.sh
>
> (BUILDTEST_MCU_GROUP can be chosen from .travis.yml)? That's exactly the
> script that Travis is using. You can also run `make buildtest` to build a
> single application for all boards and the unittests can be executed with
> `make all test`.
>
> Cheers,
> Martine
>
> 2016-03-02 15:23 GMT+01:00 TamGiang Tam :
>
>> I'm second to Nick's sugestion. Nice to have 'make' to run unit tests and
>> compile examples.
>>
>> Vào 19:00 Th 4, 02 thg 3 2016 DipSwitch  viết:
>>
>>> Would it be an idea to add a make commando to run most off the tests
>>> that travis runs? Like the static tests and different board builts, or a
>>> sub set.
>>>
>>> It would be great if this could be run from the RIOT root directory. :)
>>>
>>> Nick
>>> On 2 Mar 2016 11:59, "Francisco Javier Acosta Padilla" <
>>> francisco.aco...@inria.fr> wrote:
>>>
 Hey!

 Some tears came out of my eyes when reading this message, I never gave
 any thought to the T-guy, lots of pressure on him and nobody but you took
 care of this…

 Thanks and next time we can try to be aware of this problem.

 Cheers!

 Paco.


 On 2 March 2016 at 11:52:01, Oleg Hahm (oliver.h...@inria.fr) wrote:

 Hey Cenk!

 Thanks for this very important reminder!

 Cheers,
 Oleg

 On Wed, Mar 02, 2016 at 07:59:36AM +0100, Cenk Gündogan wrote:
 > Dear Developers,
 >
 > This is a friendly reminder that we should take more care
 > of our travis backlog.
 >
 > Everytime a pull request gets rebased/squashed/new commits
 > travis will enqueue a new task. This enqueing takes up space
 > in the travis backlog and hinders us from getting quick feedback
 > about important pull requests, which are basically ready to merge.
 >
 > I know that everyone loves to see her/his pull request checked
 > by travis as soon as possible as means of a smoke test,
 > but this "first check" can almost always be done by compiling
 locally!
 >
 > So please follow these two steps:
 > 1) If your pull request has commits with a message
 > that includes "SQUASH" or "FIXME" then travis will fail
 > anyways. So why let it enqueue at the first place?
 > Please use "[ci skip]" somewhere in your commit message
 > if this is the case. Travis will ignore a pull request if the last
 > commit
 > message has "[ci skip]" somewhere in it.
 >
 > 2) (Maintainers only) If you notice several jobs in Travis for the
 same
 > pull request, then please take the initiative and stop old jobs
 > for obsolete commits.
 >
 > I also know that it's sometimes inevitable, especially when the pull
 request
 > was already squashed and is basically ready to merge, but another
 small
 > remark forces us to commit/amend a change. (This often happens at
 > hack'n'acks)
 > If a maintainer is involved in this, then again, a pointer to 2),
 cancel
 > jobs for obsolete commits.
 >
 > Take a glance at our current travis backlog [1]. The queue is still
 full
 > from yesterday's
 > hack'n'ack session, and that was about 8-9 hours ago.
 >
 > Develop cautiously!
 >
 > Cenk
 >
 > [1] https://travis-ci.org/RIOT-OS/RIOT/pull_requests
 > ___
 > devel mailing list
 > devel@riot-os.org
 > https://lists.riot-os.org/mailman/listinfo/devel

 --
 printk(KERN_DEBUG "%s: Done reprogramming Xilinx, %d bits, good
 luck!\n",...);
 linux-2.6.6/drivers/net/wan/lmc/lmc_main.c
 --
 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel


 ___
 devel mailing list
 devel@riot-os.org
 https://lists.riot-os.org/mailman/listinfo/devel

 ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org

Re: [riot-devel] Networking Module does not appear in process list

[Bernhard Nägele]

Hello malo,
the output of ps show at me the same as you have posted it here with the
exception that there is no at86rfxx. The at86rf2xx driver is compiled - 
I see it there.
And I have no hint - no error message or something like that why it 
isn't loaded.
It seem for me, that at86rf2xx_init is not executed - that 
auto_init_at86rf2xx was
not inivolved in the init-phase. I will check this tomorrow with the 
emulator...
If so - which action/module invokes the execution of 
auto_init_at86rf2xx?  As far

I have seen this are gnrc-netif modules?
Thanks a lot,
Bernhard
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Networking Module does not appear in process list

[malo]

Hello Bernhard,

if you are using rf233 the name of the thread is at86rfxx - check with ps
output. you should get something like
> ps
pid |name | stateQ | pri | stack ( used) | location
  1 |idle |  pending Q |  15 |   128 (   96) | 267a
  2 |main |  running Q |   7 |   640 (  440) | 1880
  3 | 6lo |bl rx _ |   3 |   512 (  460) | 1d00
  4 |ipv6 |bl rx _ |   4 |   640 (  484) | 1380
  5 | udp |bl rx _ |   5 |   512 (  208) | 1f00
  6 |at86rfxx |bl rx _ |   3 |   640 (  312) | 1100
  7 |   blink | sleeping _ |   7 |   640 (  180) | 1600

in the function auto_init_at86rf2xx the thread is created only if the radio
was successfully initialized.
do you have no error return from the at86rf2xx_init?

note that im newbie as well:)

wbr
malo

On 2 March 2016 at 23:37, Bernhard Nägele 
wrote:

> Hello Peter,
> thank you.
> Just for your understanding - I just tried to make everything exactly as
> shown in the Iotlab-M3 board but I get not the result which is listed in
> the readme files or the other documentation.
> One remark - I think most new RIOT users would resolve their problems by
> themself if they have some documentation about the relationship between the
> modules. It would be also nice to now where it is the right place for
> adding a module (makefile in the board directory / makefile in the project
> directory / makefile in the top directory e.g.).
> Where is the correct place to invoke auto_init (I guess the Makefile in
> the project directory)? Is it necessary to load the radio module driver
> manually or will it be loaded automatic (by the make utility)?
> You see - a newbie has totally different questions than an implementer who
> works with RIOT since for a long time.
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Networking Module does not appear in process list

[Bernhard Nägele]

Hello Peter,
thank you.
Just for your understanding - I just tried to make everything exactly as 
shown in the Iotlab-M3 board but I get not the result which is listed in 
the readme files or the other documentation.
One remark - I think most new RIOT users would resolve their problems by 
themself if they have some documentation about the relationship between 
the modules. It would be also nice to now where it is the right place 
for adding a module (makefile in the board directory / makefile in the 
project directory / makefile in the top directory e.g.).
Where is the correct place to invoke auto_init (I guess the Makefile in 
the project directory)? Is it necessary to load the radio module driver 
manually or will it be loaded automatic (by the make utility)?
You see - a newbie has totally different questions than an implementer 
who works with RIOT since for a long time.

___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Networking Module does not appear in process list

[Peter Kietzmann]

Hi Bernhard,

without looking into details of your problem, just a quick hint from my 
side: The mac layer (nomac) and the device driver are running in the 
same thread which should be automatically initialized in our networking 
examples. I don't remember the name of the thread out of my head...


Did that already help a bit?

Best
Peter

Am 02.03.2016 um 22:57 schrieb Bernhard Nägele:

Hello everybody,
today I tried to get the at86rf2xx working with my board. I have the
following statement in the board's Makefile:

ifneq (,$(filter gnrc_netif_default,$(USEMODULE)))
 USEMODULE += at86rf233
 USEMODULE += gnrc_nomac
endif

I tried all the networking examples but no example shows the at86rf2xx
networking module when I list the threads.
I see all networking threads but not the driver.

I tried to include (USEMODULE) the Module  in the project makefile and
then i tried to invoke the auto_init mechanism on serveral places -> no
success.

Can you please tell me what I have to do to load the radio module
driver? I think it would be a good idea to write down how it should go
in a tutorial. It's not very nice for newbies to grep through the source
code to find out how it should work and what might go wrong (it a little
bit like beeing Sherlock Holmes but without having fun).

Question 2 - ifconfig:
ifconfig help
usage: ifconfig []

 From where do I get the if_id ?
I think you will get it if you invoke ifconfig without parameters (when
you have a network module thread running). Is this true?

Thanks a lot!
Regards,
Bernhard



___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel


--
Peter Kietzmann

Hamburg University of Applied Sciences
Dept. Informatik, Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49-40-42875-8426
Web: http://www.haw-hamburg.de/inet
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Networking Module does not appear in process list

[Bernhard Nägele]

Hello everybody,
today I tried to get the at86rf2xx working with my board. I have the 
following statement in the board's Makefile:


ifneq (,$(filter gnrc_netif_default,$(USEMODULE)))
USEMODULE += at86rf233
USEMODULE += gnrc_nomac
endif

I tried all the networking examples but no example shows the at86rf2xx 
networking module when I list the threads.

I see all networking threads but not the driver.

I tried to include (USEMODULE) the Module  in the project makefile and 
then i tried to invoke the auto_init mechanism on serveral places -> no 
success.


Can you please tell me what I have to do to load the radio module 
driver? I think it would be a good idea to write down how it should go 
in a tutorial. It's not very nice for newbies to grep through the source 
code to find out how it should work and what might go wrong (it a little 
bit like beeing Sherlock Holmes but without having fun).


Question 2 - ifconfig:
ifconfig help
usage: ifconfig []

From where do I get the if_id ?
I think you will get it if you invoke ifconfig without parameters (when 
you have a network module thread running). Is this true?


Thanks a lot!
Regards,
Bernhard



___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Travis Backlog

[Martine Lenders]

Hi,

do you mean

BUILDTEST_MCU_GROUP=foobar ./dist/tools/travis-scripts/build_and_test.sh

(BUILDTEST_MCU_GROUP can be chosen from .travis.yml)? That's exactly the
script that Travis is using. You can also run `make buildtest` to build a
single application for all boards and the unittests can be executed with
`make all test`.

Cheers,
Martine

2016-03-02 15:23 GMT+01:00 TamGiang Tam :

> I'm second to Nick's sugestion. Nice to have 'make' to run unit tests and
> compile examples.
>
> Vào 19:00 Th 4, 02 thg 3 2016 DipSwitch  viết:
>
>> Would it be an idea to add a make commando to run most off the tests that
>> travis runs? Like the static tests and different board builts, or a sub set.
>>
>> It would be great if this could be run from the RIOT root directory. :)
>>
>> Nick
>> On 2 Mar 2016 11:59, "Francisco Javier Acosta Padilla" <
>> francisco.aco...@inria.fr> wrote:
>>
>>> Hey!
>>>
>>> Some tears came out of my eyes when reading this message, I never gave
>>> any thought to the T-guy, lots of pressure on him and nobody but you took
>>> care of this…
>>>
>>> Thanks and next time we can try to be aware of this problem.
>>>
>>> Cheers!
>>>
>>> Paco.
>>>
>>>
>>> On 2 March 2016 at 11:52:01, Oleg Hahm (oliver.h...@inria.fr) wrote:
>>>
>>> Hey Cenk!
>>>
>>> Thanks for this very important reminder!
>>>
>>> Cheers,
>>> Oleg
>>>
>>> On Wed, Mar 02, 2016 at 07:59:36AM +0100, Cenk Gündogan wrote:
>>> > Dear Developers,
>>> >
>>> > This is a friendly reminder that we should take more care
>>> > of our travis backlog.
>>> >
>>> > Everytime a pull request gets rebased/squashed/new commits
>>> > travis will enqueue a new task. This enqueing takes up space
>>> > in the travis backlog and hinders us from getting quick feedback
>>> > about important pull requests, which are basically ready to merge.
>>> >
>>> > I know that everyone loves to see her/his pull request checked
>>> > by travis as soon as possible as means of a smoke test,
>>> > but this "first check" can almost always be done by compiling locally!
>>> >
>>> > So please follow these two steps:
>>> > 1) If your pull request has commits with a message
>>> > that includes "SQUASH" or "FIXME" then travis will fail
>>> > anyways. So why let it enqueue at the first place?
>>> > Please use "[ci skip]" somewhere in your commit message
>>> > if this is the case. Travis will ignore a pull request if the last
>>> > commit
>>> > message has "[ci skip]" somewhere in it.
>>> >
>>> > 2) (Maintainers only) If you notice several jobs in Travis for the
>>> same
>>> > pull request, then please take the initiative and stop old jobs
>>> > for obsolete commits.
>>> >
>>> > I also know that it's sometimes inevitable, especially when the pull
>>> request
>>> > was already squashed and is basically ready to merge, but another
>>> small
>>> > remark forces us to commit/amend a change. (This often happens at
>>> > hack'n'acks)
>>> > If a maintainer is involved in this, then again, a pointer to 2),
>>> cancel
>>> > jobs for obsolete commits.
>>> >
>>> > Take a glance at our current travis backlog [1]. The queue is still
>>> full
>>> > from yesterday's
>>> > hack'n'ack session, and that was about 8-9 hours ago.
>>> >
>>> > Develop cautiously!
>>> >
>>> > Cenk
>>> >
>>> > [1] https://travis-ci.org/RIOT-OS/RIOT/pull_requests
>>> > ___
>>> > devel mailing list
>>> > devel@riot-os.org
>>> > https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>> --
>>> printk(KERN_DEBUG "%s: Done reprogramming Xilinx, %d bits, good
>>> luck!\n",...);
>>> linux-2.6.6/drivers/net/wan/lmc/lmc_main.c
>>> --
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>>
>>> ___
>>> devel mailing list
>>> devel@riot-os.org
>>> https://lists.riot-os.org/mailman/listinfo/devel
>>>
>>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Travis Backlog

[TamGiang Tam]

I'm second to Nick's sugestion. Nice to have 'make' to run unit tests and
compile examples.

Vào 19:00 Th 4, 02 thg 3 2016 DipSwitch  viết:

> Would it be an idea to add a make commando to run most off the tests that
> travis runs? Like the static tests and different board builts, or a sub set.
>
> It would be great if this could be run from the RIOT root directory. :)
>
> Nick
> On 2 Mar 2016 11:59, "Francisco Javier Acosta Padilla" <
> francisco.aco...@inria.fr> wrote:
>
>> Hey!
>>
>> Some tears came out of my eyes when reading this message, I never gave
>> any thought to the T-guy, lots of pressure on him and nobody but you took
>> care of this…
>>
>> Thanks and next time we can try to be aware of this problem.
>>
>> Cheers!
>>
>> Paco.
>>
>>
>> On 2 March 2016 at 11:52:01, Oleg Hahm (oliver.h...@inria.fr) wrote:
>>
>> Hey Cenk!
>>
>> Thanks for this very important reminder!
>>
>> Cheers,
>> Oleg
>>
>> On Wed, Mar 02, 2016 at 07:59:36AM +0100, Cenk Gündogan wrote:
>> > Dear Developers,
>> >
>> > This is a friendly reminder that we should take more care
>> > of our travis backlog.
>> >
>> > Everytime a pull request gets rebased/squashed/new commits
>> > travis will enqueue a new task. This enqueing takes up space
>> > in the travis backlog and hinders us from getting quick feedback
>> > about important pull requests, which are basically ready to merge.
>> >
>> > I know that everyone loves to see her/his pull request checked
>> > by travis as soon as possible as means of a smoke test,
>> > but this "first check" can almost always be done by compiling locally!
>> >
>> > So please follow these two steps:
>> > 1) If your pull request has commits with a message
>> > that includes "SQUASH" or "FIXME" then travis will fail
>> > anyways. So why let it enqueue at the first place?
>> > Please use "[ci skip]" somewhere in your commit message
>> > if this is the case. Travis will ignore a pull request if the last
>> > commit
>> > message has "[ci skip]" somewhere in it.
>> >
>> > 2) (Maintainers only) If you notice several jobs in Travis for the same
>> > pull request, then please take the initiative and stop old jobs
>> > for obsolete commits.
>> >
>> > I also know that it's sometimes inevitable, especially when the pull
>> request
>> > was already squashed and is basically ready to merge, but another small
>> > remark forces us to commit/amend a change. (This often happens at
>> > hack'n'acks)
>> > If a maintainer is involved in this, then again, a pointer to 2),
>> cancel
>> > jobs for obsolete commits.
>> >
>> > Take a glance at our current travis backlog [1]. The queue is still
>> full
>> > from yesterday's
>> > hack'n'ack session, and that was about 8-9 hours ago.
>> >
>> > Develop cautiously!
>> >
>> > Cenk
>> >
>> > [1] https://travis-ci.org/RIOT-OS/RIOT/pull_requests
>> > ___
>> > devel mailing list
>> > devel@riot-os.org
>> > https://lists.riot-os.org/mailman/listinfo/devel
>>
>> --
>> printk(KERN_DEBUG "%s: Done reprogramming Xilinx, %d bits, good
>> luck!\n",...);
>> linux-2.6.6/drivers/net/wan/lmc/lmc_main.c
>> --
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>>
>> ___
>> devel mailing list
>> devel@riot-os.org
>> https://lists.riot-os.org/mailman/listinfo/devel
>>
>> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel
>
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

[riot-devel] Two additions

[Bas Stottelaar]

Hi all,

I finally joined the mailing list :-)

Two questions about potential contributions:

* Out of personal interest I have created/implemented the Fortuna (CS)PRNG
[1,2] (still WIP + needs AES256). Contrary to the Tiny Mersenne Twister,
this PRNG is bigger and slower, but more secure. I believe native/boards
with crypto accelerators could benefit.

* I ported U8glib [3] and got it working with a SPI LCD:
https://www.youtube.com/watch?v=bG5_EwFTiDc. I already showed this on IRC,
but wanted to share this with the rest that hasn't seen it yet. It can also
emulate a display on stdout.

Would both be valuable contributions, or can I better wait for the
(hopefully upcoming) 'RIOT package manager' [4]?

Kind regards,
Bas Stottelaar

[1] https://www.schneier.com/cryptography/paperfiles/fortuna.pdf
[2] https://github.com/basilfx/RIOT/tree/feature/fortuna
[3] https://github.com/basilfx/RIOT/tree/feature/u8glib
[4] https://github.com/RIOT-OS/RIOT/pull/4478
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Travis Backlog

[Francisco Javier Acosta Padilla]

Hey!

Some tears came out of my eyes when reading this message, I never gave any 
thought to the T-guy, lots of pressure on him and nobody but you took care of 
this…

Thanks and next time we can try to be aware of this problem.

Cheers!

Paco.


On 2 March 2016 at 11:52:01, Oleg Hahm (oliver.h...@inria.fr) wrote:

Hey Cenk!  

Thanks for this very important reminder!  

Cheers,  
Oleg  

On Wed, Mar 02, 2016 at 07:59:36AM +0100, Cenk Gündogan wrote:  
> Dear Developers,  
>  
> This is a friendly reminder that we should take more care  
> of our travis backlog.  
>  
> Everytime a pull request gets rebased/squashed/new commits  
> travis will enqueue a new task. This enqueing takes up space  
> in the travis backlog and hinders us from getting quick feedback  
> about important pull requests, which are basically ready to merge.  
>  
> I know that everyone loves to see her/his pull request checked  
> by travis as soon as possible as means of a smoke test,  
> but this "first check" can almost always be done by compiling locally!  
>  
> So please follow these two steps:  
> 1) If your pull request has commits with a message  
> that includes "SQUASH" or "FIXME" then travis will fail  
> anyways. So why let it enqueue at the first place?  
> Please use "[ci skip]" somewhere in your commit message  
> if this is the case. Travis will ignore a pull request if the last  
> commit  
> message has "[ci skip]" somewhere in it.  
>  
> 2) (Maintainers only) If you notice several jobs in Travis for the same  
> pull request, then please take the initiative and stop old jobs  
> for obsolete commits.  
>  
> I also know that it's sometimes inevitable, especially when the pull request  
> was already squashed and is basically ready to merge, but another small  
> remark forces us to commit/amend a change. (This often happens at  
> hack'n'acks)  
> If a maintainer is involved in this, then again, a pointer to 2), cancel  
> jobs for obsolete commits.  
>  
> Take a glance at our current travis backlog [1]. The queue is still full  
> from yesterday's  
> hack'n'ack session, and that was about 8-9 hours ago.  
>  
> Develop cautiously!  
>  
> Cenk  
>  
> [1] https://travis-ci.org/RIOT-OS/RIOT/pull_requests  
> ___  
> devel mailing list  
> devel@riot-os.org  
> https://lists.riot-os.org/mailman/listinfo/devel  

--  
printk(KERN_DEBUG "%s: Done reprogramming Xilinx, %d bits, good luck!\n",...);  
linux-2.6.6/drivers/net/wan/lmc/lmc_main.c  
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Travis Backlog

[Oleg Hahm]

Hey Cenk!

Thanks for this very important reminder!

Cheers,
Oleg

On Wed, Mar 02, 2016 at 07:59:36AM +0100, Cenk Gündogan wrote:
> Dear Developers,
> 
> This is a friendly reminder that we should take more care
> of our travis backlog.
> 
> Everytime a pull request gets rebased/squashed/new commits
> travis will enqueue a new task. This enqueing takes up space
> in the travis backlog and hinders us from getting quick feedback
> about important pull requests, which are basically ready to merge.
> 
> I know that everyone loves to see her/his pull request checked
> by travis as soon as possible as means of a smoke test,
> but this "first check" can almost always be done by compiling locally!
> 
> So please follow these two steps:
> 1) If your pull request has commits with a message
> that includes "SQUASH" or "FIXME" then travis will fail
> anyways. So why let it enqueue at the first place?
> Please use "[ci skip]" somewhere in your commit message
> if this is the case. Travis will ignore a pull request if the last
> commit
> message has "[ci skip]" somewhere in it.
> 
> 2) (Maintainers only) If you notice several jobs in Travis for the same
> pull request, then please take the initiative and stop old jobs
> for obsolete commits.
> 
> I also know that it's sometimes inevitable, especially when the pull request
> was already squashed and is basically ready to merge, but another small
> remark forces us to commit/amend a change. (This often happens at
> hack'n'acks)
> If a maintainer is involved in this, then again, a pointer to 2), cancel
> jobs for obsolete commits.
> 
> Take a glance at our current travis backlog [1]. The queue is still full
> from yesterday's
> hack'n'ack session, and that was about 8-9 hours ago.
> 
> Develop cautiously!
> 
> Cenk
> 
> [1] https://travis-ci.org/RIOT-OS/RIOT/pull_requests
> ___
> devel mailing list
> devel@riot-os.org
> https://lists.riot-os.org/mailman/listinfo/devel

-- 
printk(KERN_DEBUG "%s: Done reprogramming Xilinx, %d bits, good luck!\n",...);
linux-2.6.6/drivers/net/wan/lmc/lmc_main.c


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel

Re: [riot-devel] Just another good reason not to implement printf() yourself

[Oleg Hahm]

Hey Malo!

On Wed, Mar 02, 2016 at 08:51:51AM +0100, malo wrote:
> that would be even better indeed.
> something like  #define LOG_PRINTF(...) LOG(LOG_PRINTF, __VA_ARGS__) and to
> forbid to use printf?

Hm, after thinking about this again, it's a bit more difficult, I guess. There
are three types of actions where I see a need for printing strings:
1.) logging (something similar to syslog or journal on Linux)
2.) debugging
3.) some kind of CLI (e.g. our shell)

1.) should be covered by LOG_* from log.h.
2.) is covered by DEBUG()
3.) still needs a concept

But in general, I agree that getting rid of printf() all over the code is
desirable.

Cheers,
Oleg
-- 
The problem with a SQL security joke is that Sony don't get it.


signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel