Re: GSoC Project : Package Micro-python
On Fri, Mar 26, 2021 at 5:46 AM Joel Sherrill wrote: > > > On Wed, Mar 24, 2021, 1:43 PM Gedare Bloom wrote: > >> On Wed, Mar 24, 2021 at 11:38 AM Eshan Dhawan >> wrote: >> > >> > >> > >> > On Wed, Mar 24, 2021 at 12:34 AM Gedare Bloom wrote: >> >> >> >> On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan >> wrote: >> >> > >> >> > >> >> > Apologies for the late reply. >> >> > >> >> > On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill >> wrote: >> >> >> >> >> >> >> >> >> >> >> >> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom >> wrote: >> >> >>> >> >> >>> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill >> wrote: >> >> >>> > >> >> >>> > >> >> >>> > >> >> >>> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom >> 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
Re: GSoC Project : Package Micro-python
On Wed, Mar 24, 2021, 1:43 PM Gedare Bloom wrote: > On Wed, Mar 24, 2021 at 11:38 AM Eshan Dhawan > wrote: > > > > > > > > On Wed, Mar 24, 2021 at 12:34 AM Gedare Bloom wrote: > >> > >> On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan > wrote: > >> > > >> > > >> > Apologies for the late reply. > >> > > >> > On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill > wrote: > >> >> > >> >> > >> >> > >> >> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom > wrote: > >> >>> > >> >>> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill > wrote: > >> >>> > > >> >>> > > >> >>> > > >> >>> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom > 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 > > >> > >> > >> >>> > >> >>> > > >> >>> > > >> >>> > 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
Re: GSoC Project : Package Micro-python
On Wed, Mar 24, 2021 at 11:38 AM Eshan Dhawan wrote: > > > > On Wed, Mar 24, 2021 at 12:34 AM Gedare Bloom wrote: >> >> On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan >> wrote: >> > >> > >> > Apologies for the late reply. >> > >> > On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill wrote: >> >> >> >> >> >> >> >> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom wrote: >> >>> >> >>> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill wrote: >> >>> > >> >>> > >> >>> > >> >>> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom wrote: >> >>> >> >> >>> >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan >> >>> >> 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 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. >> >
Re: GSoC Project : Package Micro-python
On Wed, Mar 24, 2021 at 12:34 AM Gedare Bloom wrote: > On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan > wrote: > > > > > > Apologies for the late reply. > > > > On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill wrote: > >> > >> > >> > >> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom wrote: > >>> > >>> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill wrote: > >>> > > >>> > > >>> > > >>> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom > 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 > >>> >>
Re: GSoC Project : Package Micro-python
On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan wrote: > > > Apologies for the late reply. > > On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill wrote: >> >> >> >> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom wrote: >>> >>> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill wrote: >>> > >>> > >>> > >>> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom wrote: >>> >> >>> >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan >>> >> 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. >>> >>> > >>> > >>> > 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
Re: GSoC Project : Package Micro-python
Apologies for the late reply. On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill wrote: > > > On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom wrote: > >> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill wrote: >> > >> > >> > >> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom wrote: >> >> >> >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan >> 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
Re: GSoC Project : Package Micro-python
On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom wrote: > On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill wrote: > > > > > > > > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom wrote: > >> > >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan > 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. > > > > > > 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: > > > > + 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. > 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. > 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
Re: GSoC Project : Package Micro-python
On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill wrote: > > > > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom wrote: >> >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan >> 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. > > > 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: > > + 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. 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. > --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
Re: GSoC Project : Package Micro-python
On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom wrote: > On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan > 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. > 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: + 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? --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
Re: GSoC Project : Package Micro-python
On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan 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. > 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
GSoC Project : Package Micro-python
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? Thanks - Eshan ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
