GSoC Project : Package Micro-python

[Eshan Dhawan]

On Fri, Mar 26, 2021 at 5:46 AM Joel Sherrill <joel at rtems.org> wrote:

>
>
> On Wed, Mar 24, 2021, 1:43 PM Gedare Bloom <gedare at rtems.org> wrote:
>
>> On Wed, Mar 24, 2021 at 11:38 AM Eshan Dhawan <eshandhawan51 at gmail.com>
>> wrote:
>> >
>> >
>> >
>> > 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.
>>
>> Right, please don't include that. You'll want to think/talk through
>> (with Joel, maybe) what could be good code contributions. If the RSB
>> packaging is fairly minimal, then creating a suite of examples might
>> be one way to increase the SLOC contributions. I also think there is
>> merit to the idea of creating a "plug-in" way to add shells to RTEMS.
>> Maybe even refactoring our current shell out to a add-on package then.
>> Just a thought.
>>
>
> I'd rather see two languages with good packaging, examples for RTEMS use
> cases, and documentation. It's a fair project.
>
> If you get through those, we can find another language. TCL probably. I
> don't expect Forth or  LISP to be high on the list. Lol
>
We can figure that out while framing the proposal time management section.
That how many languages can be packaged.
Currently, the scope of the project is to be determined so I can start with
the Proposal.

>
>> >>
>> >>
>> >> >>>
>> >> >>> >
>> >> >>> >
>> >> >>> > 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/20210327/857ceaf1/attachment.html>