On 2/8/19 6:10 pm, Sebastian Huber wrote:
> Hello,
>
> the EOL of Python 2.7 is soon, so it will be Python 3 for sure:
>
> https://pythonclock.org/
>
> The EOL of Python 3.4 was March 18, 2019:
>
> https://www.python.org/downloads/release/python-3410/
>
> Is it all right to start with Python 3
On 05/08/2019 06:54, Ravindra Kumar Meena wrote:
*Plan of the week:*
Last week I did some tweak in client program for the idle thread so that
more details are visible in Trace Compass. I will continue to work on
the client program and will produce documentation for the same.
In the console ou
*Plan of the week:*
Last week I did some tweak in client program for the idle thread so that
more details are visible in Trace Compass. I will continue to work on the
client program and will produce documentation for the same.
In the console output at someplace, I am getting this type of output:
On 2/8/19 10:59 pm, Himanshu Sekhar Nayak wrote:
> Sorry for late reply as I am busy here for admission in an university.
That is fine and all the best in your studies.
> So I
> tried the solution suggested by you and it somewhere got build failed. This
> time
> it didn't asked for sudo privile
On 5/8/19 2:41 am, Christian Mauderer wrote:
> I'm still not entirely happy with the pinmux because it re-initializes
> some pins that are already initialized by the BSP. But if no one has a
> better idea that can be done in a reasonable time I would accept it like
> it is. I think I would prefer i
Hello Vijay,
for the whole patch set:
The order and groups are good now. I didn't find anything where I would
have big problems. All patches are compilable and libbsd still compiles
on a PowerPC target. The result is great (with some demo application I
get an image on the screen). So I'm OK with
- Am 4. Aug 2019 um 9:54 schrieb Ravindra Kumar Meena rmeena...@gmail.com:
> We don't really need so many sched_switch events in the metadata. I have
> removed the extra events.
>
>>
> https://github.com/rmeena840/rtems-tools/commit/61003e8013146acf400a79fb9dea982242f5c6af
>
> And for the sa
- Am 3. Aug 2019 um 18:16 schrieb Ravindra Kumar Meena rmeena...@gmail.com:
> Now, I can get the [thread_id] and [thread_name] in print_item() but since
> this information is not CPU specific so in which CPU should I store this
> information?
Maybe something like this (please remove your hash
We don't really need so many sched_switch events in the metadata. I have
removed the extra events.
>
https://github.com/rmeena840/rtems-tools/commit/61003e8013146acf400a79fb9dea982242f5c6af
And for the same, I have made changes in the client program.
https://github.com/rmeena840/rtems-tools/comm
