GSoC Project : Package Micro-python

[Eshan Dhawan]

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.

> >
>> >
>> > 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 :)

>
> 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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210323/3366377c/attachment.html>