On Wed, Mar 24, 2021 at 12:34 AM Gedare Bloom <ged...@rtems.org> wrote:
> On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan <eshandhawa...@gmail.com> > wrote: > > > > > > 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. > > 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@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