[GSOC] Introduction and Microproject

[Srikavin Ramkumar]

On Mon Apr 12, 2021 at 2:48 AM, Elvira Khabirova wrote:
> On Sat, 10 Apr 2021 23:53:56 -0400
> "Srikavin Ramkumar" <srikavinramkumar at gmail.com> wrote:
>
> 
> > Hi Elvira,
> > 
> > Thanks for the feedback.
> > 
> > On Sun Apr 11, 2021 at 2:02 AM, Elvira Khabirova wrote:
> > > Hello,
> > >
> > > 
> > > On Mon, 05 Apr 2021 17:49:33 -0400
> > > "Srikavin Ramkumar" <srikavinramkumar at gmail.com> wrote:
> > >
> > > 
> > > > Hi,
> > > > 
> > > > I have finished my draft GSoC proposal [1]; I have also uploaded it in the
> > > > student dashboard. I would appreciate any questions or feedback.
> > > > 
> > > > [1]: https://hackmd.io/@srikavin/SJSl2RaNd
> > >
> > > 
> > > Your proposal looks elaborate and well thought out.
> > >
> > >
> > > Some things to consider:
> > >
> > > 
> > > - We would appreciate if you used flex/bison for parsing syzlang instead
> > > of Python. This is more in line with the project's general style, and
> > > some might
> > > argue that using a specialized tool would be more appropriate for the
> > > task.
> > 
> > I would be comfortable with using either C with flex/bison or Python. I agree
> > that using a specialized tool for lexing and parsing regardless of language
> > choice is a good idea since it will reduce complexity and future maintenance
> > work. 
> > 
> > However, I think string processing and code generation would be significantly
> > simpler with Python than with C. The downsides of using Python would also be
> > limited if the generated code is committed alongside modifications to the
> > underlying syzlang files.
>
> 
> I don't really understand this point, since yes, the generator is going
> to
> be placed in maint/, and yes, the generated parsers are going to be
> manually
> commited, but it doesn't make the generator implementation details less
> important; but...
>
> 
> > Is using C a hard requirement?
>
> 
> ...yeah, I'm afraid it is. But most of the string processing is going to
> be
> handled by flex/bison anyway.
>

Ok. That makes sense. I'll look closer at bison/flex and update my proposal to 
reflect these changes tomorrow.

> 
> > > - Your actual timeline will likely differ from the one you've drafted,
> > > because
> > > merging the changes usually takes as long as the main coding process.
> > 
> > I've made some changes to the timeline so that I have four total buffer weeks
> > that I can use for merging. 
> > 
> > Thanks,
> > Srikavin
>
> 
> --
> Strace-devel mailing list
> Strace-devel at lists.strace.io
> https://lists.strace.io/mailman/listinfo/strace-devel
>
> 
>
>