I am drafting a proposal for this, Will submit it as soon as possible,
Possibly by tomorrow. I am getting an idea and I will try to match the
ticket deliverables.
Best Regards
Anmol
On Sat, Feb 29, 2020 at 12:39 AM Amar Takhar wrote:
> On 2020-02-28 12:39 -0600, Joel Sherrill wrote:
> >
> > We
On 2020-02-29 04:18, Amar Takhar wrote:
On 2020-02-28 09:25 -0700, Gedare Bloom wrote:
If there is enough work, and the work can be suitably identified, then
it can also be a possible GSoC. There are also other possibilities to
improve our existing Python code bases to adhere to some proposed
On 2020-02-28 12:39 -0600, Joel Sherrill wrote:
>
> We can't blanket upgrade tools to Python 3. The only thing I think we agreed
> when this was recently discussed is that we have categories of tools in Python
> and some have to be compatible with Python 2 and 3.
I wasn't suggesting that. I said
On Fri, Feb 28, 2020 at 11:18 AM Amar Takhar wrote:
> On 2020-02-28 09:25 -0700, Gedare Bloom wrote:
> > >
> > If there is enough work, and the work can be suitably identified, then
> > it can also be a possible GSoC. There are also other possibilities to
> > improve our existing Python code base
On 2020-02-28 09:25 -0700, Gedare Bloom wrote:
> >
> If there is enough work, and the work can be suitably identified, then
> it can also be a possible GSoC. There are also other possibilities to
> improve our existing Python code bases to adhere to some proposed
> Python coding conventions, which
On Fri, Feb 28, 2020 at 5:10 AM Christian Mauderer
wrote:
>
> Hello Anmol,
>
> On 28/02/2020 10:49, Anmol Mishra wrote:
> > I can see python2 code being used. And as of 2020 python2 has been
> > depreciated but I assume everyone is aware of that. Is there any active
> > plan to shift the codebase.
Hello Anmol,
On 28/02/2020 10:49, Anmol Mishra wrote:
> I can see python2 code being used. And as of 2020 python2 has been
> depreciated but I assume everyone is aware of that. Is there any active
> plan to shift the codebase. I am open to discussion for this.
We have the problem that some long
-- Original --
From: "Chris Johns"___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
On 10/2/20 12:14 pm, jameszxj wrote:
> The caches size(RTEMS_RTL_ELF_SYMBOL_CACHE ...) now are just define in
> rtl.c.
Yes.
> One of our project should increase the cache size, so I have to modify the
> kernel source file directly. I think if the cache size can be redefined maybe
> friendly.
