<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Mar 24, 2021, 1:43 PM Gedare Bloom <<a href="mailto:gedare@rtems.org" target="_blank" rel="noreferrer">gedare@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Wed, Mar 24, 2021 at 11:38 AM Eshan Dhawan <<a href="mailto:eshandhawan51@gmail.com" rel="noreferrer noreferrer" target="_blank">eshandhawan51@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Wed, Mar 24, 2021 at 12:34 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" rel="noreferrer noreferrer" target="_blank">gedare@rtems.org</a>> wrote:<br>
>><br>
>> On Tue, Mar 23, 2021 at 12:16 PM Eshan Dhawan <<a href="mailto:eshandhawan51@gmail.com" rel="noreferrer noreferrer" target="_blank">eshandhawan51@gmail.com</a>> wrote:<br>
>> ><br>
>> ><br>
>> > Apologies for the late reply.<br>
>> ><br>
>> > On Mon, Mar 22, 2021 at 10:27 PM Joel Sherrill <<a href="mailto:joel@rtems.org" rel="noreferrer noreferrer" target="_blank">joel@rtems.org</a>> wrote:<br>
>> >><br>
>> >><br>
>> >><br>
>> >> On Mon, Mar 22, 2021 at 11:55 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" rel="noreferrer noreferrer" target="_blank">gedare@rtems.org</a>> wrote:<br>
>> >>><br>
>> >>> On Mon, Mar 22, 2021 at 10:50 AM Joel Sherrill <<a href="mailto:joel@rtems.org" rel="noreferrer noreferrer" target="_blank">joel@rtems.org</a>> wrote:<br>
>> >>> ><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > On Mon, Mar 22, 2021 at 11:30 AM Gedare Bloom <<a href="mailto:gedare@rtems.org" rel="noreferrer noreferrer" target="_blank">gedare@rtems.org</a>> wrote:<br>
>> >>> >><br>
>> >>> >> On Sat, Mar 20, 2021 at 12:33 PM Eshan Dhawan <<a href="mailto:eshandhawan51@gmail.com" rel="noreferrer noreferrer" target="_blank">eshandhawan51@gmail.com</a>> wrote:<br>
>> >>> >> ><br>
>> >>> >> > Hello Everyone,<br>
>> >>> >> > I wanted to take Packaging Micro Python up as GSOC project this summer and the project will also include packaging LUA and picoC<br>
>> >>> >> > The ticket for Micro Python  : <a href="https://devel.rtems.org/ticket/4349" rel="noreferrer noreferrer noreferrer" target="_blank">https://devel.rtems.org/ticket/4349</a><br>
>> >>> >> > What would be the complete Scope of the project?<br>
>> >>> >> > And what would be a good starting point?<br>
>> >>> >> ><br>
>> >>> >><br>
>> >>> >> Well, I guess Joel must have described the task, so I'll leave it to<br>
>> >>> >> him to fill in some more details.<br>
>> >>> >><br>
>> >>> >> Adding RSB packages may be not sufficient coding work for GSoC. It is<br>
>> >>> >> important in the proposal to identify what would be the coding<br>
>> >>> >> activities involved in this project. For example, we know from<br>
>> >>> >> experience that Lua can just be built from some minor tailoring of its<br>
>> >>> >> Makefile, so the package is very straightforward. However, the<br>
>> >>> >> projects you mention are scripting environments, so maybe creating a<br>
>> >>> >> framework in RTEMS for a "shell/intepreter" that can be built as an<br>
>> >>> >> add-on by RSB would be a proper way to scope this effort<br>
>> ><br>
>> > 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.<br>
>><br>
>> Remember that code is what counts, while we expect the other stuff to<br>
>> come along too, you don't want to be doing 90% doco and 10% code. Just<br>
>> keep it in mind.<br>
><br>
> What would be a good inclusion to this project ?<br>
> I was thinking long double support since I worked on porting POSIX functions I might find it easier.<br>
> But it might interfere with matt's project if I understand that project correctly.<br>
<br>
Right, please don't include that. You'll want to think/talk through<br>
(with Joel, maybe) what could be good code contributions. If the RSB<br>
packaging is fairly minimal, then creating a suite of examples might<br>
be one way to increase the SLOC contributions. I also think there is<br>
merit to the idea of creating a "plug-in" way to add shells to RTEMS.<br>
Maybe even refactoring our current shell out to a add-on package then.<br>
Just a thought.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">I'd rather see two languages with good packaging, examples for RTEMS use cases, and documentation. It's a fair project.</div><div dir="auto"><br></div><div dir="auto">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</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
>><br>
>><br>
>> >>><br>
>> >>> ><br>
>> >>> ><br>
>> >>> > I agree that Lua and Micropython should build easy but I had more<br>
>> >>> > in mind.<br>
>> >>> ><br>
>> >>> > The full project was language stacks for RTEMS with a better user<br>
>> >>> > experience for Micropython, Lua, Tcl, etc although I am not sure what<br>
>> >>> > etc would entail. I am not sure all three can be completed in the new<br>
>> >>> > GSoC timeframe. All would follow the same pattern:<br>
>> ><br>
>> > Etc can be managed while framing the proposal according to how time is being managed.<br>
>> >>><br>
>> >>> ><br>
>> >>> > + RSB package offering a reasonable default and access to configuration<br>
>> >>> > + Examples including at least bare embedded, use of custom commands,<br>
>> >>> > and integrating with RTEMS shell commands Perhaps  interactive use with<br>
>> >>> > command line history and editing integrated if we have that as a library now.<br>
>> >>> > + Documentation specific to RTEMS and the examples<br>
>> >>> ><br>
>> >>> > I imagined completely parallel kits for each embedded language we wanted<br>
>> >>> > to support.<br>
>> >>> ><br>
>> >>> > Does that help? Should he plan on Micropython and Lua?<br>
>> >>> ><br>
>> >>><br>
>> >>> Sure. Lua should be easy way to get started and develop the<br>
>> >>> framework/infrastructure side in Phase 1. Phase 2 could be extension<br>
>> >>> to micropython / other scripting languages.<br>
>> ><br>
>> > Since all the languages will have a similar pattern complex work can be put in phase 2.<br>
>> > From my past experience, it is the part when most work is done :)<br>
>><br>
>> True, but for repeat students, we do expect a bit more acceleration in<br>
>> the first phase. Usually, we want to see code merged in phase 1 by<br>
>> repeat students. Just a reminder that the bar is higher :)<br>
><br>
> :)<br>
>><br>
>><br>
>> >><br>
>> >><br>
>> >> OK.<br>
>> >>><br>
>> >>><br>
>> >>> I'm not sure about the RSB design of things, and whether they should<br>
>> >>> be parallel or capable of integration. Would anyone want to use<br>
>> >>> multiple interpreters in the same application? If so, they should<br>
>> >>> build together to avoid conflicts. If not, parallel is fine.<br>
>> ><br>
>> > building them can be set to build flags,<br>
>> > but there still needs to be a way if we want to build the package other than the default way.<br>
>> > (any ideas on how to do that )<br>
>> >><br>
>> >><br>
>> >> I don't see any reason on our side why that shouldn't work but we<br>
>> >> can't guarantee they don't have symbol conflicts. And I'm not sure<br>
>> >> it would make much sense to integrate both at the same time.<br>
>> >><br>
>> >> I'd think you could install both but we'd focus on only using one<br>
>> >> at a time.<br>
>> >><br>
>> >> --joel<br>
>> >>><br>
>> >>><br>
>> >>> > --joel<br>
>> >>> ><br>
>> >>> >><br>
>> >>> >> > Thanks<br>
>> >>> >> > - Eshan<br>
>> >>> >> > _______________________________________________<br>
>> >>> >> > devel mailing list<br>
>> >>> >> > <a href="mailto:devel@rtems.org" rel="noreferrer noreferrer" target="_blank">devel@rtems.org</a><br>
>> >>> >> > <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
>> >>> >> _______________________________________________<br>
>> >>> >> devel mailing list<br>
>> >>> >> <a href="mailto:devel@rtems.org" rel="noreferrer noreferrer" target="_blank">devel@rtems.org</a><br>
>> >>> >> <a href="http://lists.rtems.org/mailman/listinfo/devel" rel="noreferrer noreferrer noreferrer" target="_blank">http://lists.rtems.org/mailman/listinfo/devel</a><br>
</blockquote></div></div></div>