GSoC Project : Package Micro-python

[Eshan Dhawan]

On Wed, Mar 24, 2021 at 12:34 AM Gedare Bloom <gedare at rtems.org> wrote:

> 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.
>
What would be a good inclusion to this project ?
I was thinking long double support since I worked on porting POSIX
functions I might find it easier.
But it might interfere with matt's project if I understand that project
correctly.

>
> >>>
> >>> >
> >>> >
> >>> > 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20210324/529dc2a9/attachment-0001.html>