GSoC Project : Package Micro-python

[Gedare Bloom]

On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan <eshandhawan51 at gmail.com> wrote:
>
>
> Apologies for the late reply.
>
> On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill <joel at rtems.org> wrote:
>>
>>
>>
>> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom <gedare at rtems.org> wrote:
>>>
>>> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill <joel at rtems.org> wrote:
>>> >
>>> >
>>> >
>>> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom <gedare at rtems.org> wrote:
>>> >>
>>> >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan <eshandhawan51 at gmail.com> wrote:
>>> >> >
>>> >> > Hello Everyone,
>>> >> > I wanted to take Packaging Micro Python up as GSOC project this summer and the project will also include packaging LUA and picoC
>>> >> > The ticket for Micro Python  : https://devel.rtems.org/ticket/4349
>>> >> > What would be the complete Scope of the project?
>>> >> > And what would be a good starting point?
>>> >> >
>>> >>
>>> >> Well, I guess Joel must have described the task, so I'll leave it to
>>> >> him to fill in some more details.
>>> >>
>>> >> Adding RSB packages may be not sufficient coding work for GSoC. It is
>>> >> important in the proposal to identify what would be the coding
>>> >> activities involved in this project. For example, we know from
>>> >> experience that Lua can just be built from some minor tailoring of its
>>> >> Makefile, so the package is very straightforward. However, the
>>> >> projects you mention are scripting environments, so maybe creating a
>>> >> framework in RTEMS for a "shell/intepreter" that can be built as an
>>> >> add-on by RSB would be a proper way to scope this effort
>
> Packaging might not be a lot of coding part but adding its documentation and its example would be a very iterative and time consuming process.

Remember that code is what counts, while we expect the other stuff to
come along too, you don't want to be doing 90% doco and 10% code. Just
keep it in mind.

>>>
>>> >
>>> >
>>> > I agree that Lua and Micropython should build easy but I had more
>>> > in mind.
>>> >
>>> > The full project was language stacks for RTEMS with a better user
>>> > experience for Micropython, Lua, Tcl, etc although I am not sure what
>>> > etc would entail. I am not sure all three can be completed in the new
>>> > GSoC timeframe. All would follow the same pattern:
>
> Etc can be managed while framing the proposal according to how time is being managed.
>>>
>>> >
>>> > + RSB package offering a reasonable default and access to configuration
>>> > + Examples including at least bare embedded, use of custom commands,
>>> > and integrating with RTEMS shell commands Perhaps  interactive use with
>>> > command line history and editing integrated if we have that as a library now.
>>> > + Documentation specific to RTEMS and the examples
>>> >
>>> > I imagined completely parallel kits for each embedded language we wanted
>>> > to support.
>>> >
>>> > Does that help? Should he plan on Micropython and Lua?
>>> >
>>>
>>> Sure. Lua should be easy way to get started and develop the
>>> framework/infrastructure side in Phase 1. Phase 2 could be extension
>>> to micropython / other scripting languages.
>
> Since all the languages will have a similar pattern complex work can be put in phase 2.
> From my past experience, it is the part when most work is done :)

True, but for repeat students, we do expect a bit more acceleration in
the first phase. Usually, we want to see code merged in phase 1 by
repeat students. Just a reminder that the bar is higher :)

>>
>>
>> OK.
>>>
>>>
>>> I'm not sure about the RSB design of things, and whether they should
>>> be parallel or capable of integration. Would anyone want to use
>>> multiple interpreters in the same application? If so, they should
>>> build together to avoid conflicts. If not, parallel is fine.
>
> building them can be set to build flags,
> but there still needs to be a way if we want to build the package other than the default way.
> (any ideas on how to do that )
>>
>>
>> I don't see any reason on our side why that shouldn't work but we
>> can't guarantee they don't have symbol conflicts. And I'm not sure
>> it would make much sense to integrate both at the same time.
>>
>> I'd think you could install both but we'd focus on only using one
>> at a time.
>>
>> --joel
>>>
>>>
>>> > --joel
>>> >
>>> >>
>>> >> > Thanks
>>> >> > - Eshan
>>> >> > _______________________________________________
>>> >> > devel mailing list
>>> >> > devel at rtems.org
>>> >> > http://lists.rtems.org/mailman/listinfo/devel
>>> >> _______________________________________________
>>> >> devel mailing list
>>> >> devel at rtems.org
>>> >> http://lists.rtems.org/mailman/listinfo/devel