On Fri, Mar 26, 2021 at 5:46 AM Joel Sherrill <j...@rtems.org> wrote:
> > > On Wed, Mar 24, 2021, 1:43 PM Gedare Bloom <ged...@rtems.org> wrote: > >> On Wed, Mar 24, 2021 at 11:38 AM Eshan Dhawan <eshandhawa...@gmail.com> >> wrote: >> > >> > >> > >> > 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. >> >> 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@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