Apologies for the late reply. On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill <j...@rtems.org> wrote:
> > > On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom <ged...@rtems.org> wrote: > >> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill <j...@rtems.org> wrote: >> > >> > >> > >> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom <ged...@rtems.org> wrote: >> >> >> >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan <eshandhawa...@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@rtems.org >> >> > http://lists.rtems.org/mailman/listinfo/devel >> >> _______________________________________________ >> >> devel mailing list >> >> devel@rtems.org >> >> http://lists.rtems.org/mailman/listinfo/devel >> >
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
