Re: GSoC Timeline Review

[David Malcolm <dmalcolm@redhat.com>]

On Sat, 2024-03-30 at 13:54 +0200, Nada Elsayed wrote:
> I think that I didn't fully understand the project, so I read more
> and
> updated the Timeline Suggestion.

Hi Nada

I'm very sorry for not responding sooner; I've been dealing with an 
difficult issue that's arisen outside of my computer work, but that's a
poor excuse.

The deadline for applications is in a few hours time, so please go
ahead and get an application in if you haven't done so already.  Google
are very strict about the deadlines.

Amongst other things, a good application should:

* describe/give evidence of your ability/skills in C++ (e.g. do you
have a github account?)
* describe/give evidence of your knowledge of the CPython extension
API.  I think you mentioned that you had done a experimented with this
to get a feel for it, and wrote some toy examples; can you send me the
code you wrote please?

If you've already posted an application, feel free to send this info
separately to me (and I'm sorry again for leaving my reply so late).

Have you tried building GCC from source yet?  That would be a good
thing to do (and to mention in an application).

Various notes inline below, throughout...

> 
> Suggested Timeline:
> 
>    -
> 
>    May 1-26:
>    -
> 
>       Explore Cython modules and try more realistic codes to see how
> it
>       translates Python to c/c++.


Note that "Cython" and "CPython" are different things.

"CPython" is the C implementation of Python (i.e. the one that most
people use, as opposed to, say, PyPy, which is a different
implementation of the language used by advanced users with performance
requirements).

"Cython" is a tool for generating .c source files for CPython extension
modules from a .pyx language that's a mixture of C and Python-like
syntax.

The project should primarily be about CPython extension modules.  The
code generated by Cython tends to be correct, so I'm much less
interested in analyzing it.

So in your proposal above it should talk about CPython, rather than
Cython.

>       -
> 
>       Know more about entry-points that Cython uses.

Similarly here.



>       -
> 
>       Understand common bugs that happen when converting Python to
> c/c++.
> 
> 
> 
>    -
> 
>    Explore static analysis tool for CPython Extension code -which is
>    written in Python- and try this analyzer to understand the bugs in
>    translated Python code fully.

Sadly this old project of mine has been bit-rotting for years, and
doesn't work well anymore.  But hopefully it's still useful for getting
ideas.

>    -
> 
>    Know how we can emit warnings and errors.
> 
> 
> 
>    -
> 
>    Debug the codebase to grasp its structure and potential areas for
>    improvement.

I'd like us also to create a page on the gcc wiki to capture some of
the ideas.

> 
> 
>    -
> 
>    Weeks 1-2:
>    -
> 
>       Understand more about reference counting verification.
>       -
> 
>       Develop verifying reference counts for PyObjects passed as
> parameters.
>       -
> 
>    Weeks 3-4:
>    -
> 
>       Begin to investigate Error Handling Checking.
>       -
> 
>       Understand how the Static Analysis tool does Error Handling
> checking.
>       -
> 
>       Implement these checks in the plugin.
>       -
> 
>    Weeks 5-7:
>    -
> 
>       Begin to investigate Exception Handling Checking.
>       -
> 
>       Understand how the Static Analysis tool does Exception Handling
>       checking.
>       -
> 
>       Implement these checks in the plugin.
>       -
> 
>    Weeks 8-11
>    -
> 
>       Begin to investigate Format String Checking.
>       -
> 
>       Understand how the Static Analysis tool does Format String
> Checking.
>       -
> 
>       Implement these checks in the plugin.
>       -
> 
>    Week 12
>    -
> 
>       Writing the GSoC wrapping-up document.

This timeline is very ambitious; last year Eric spent a lot of time
simply understanding the way the analyzer represents the state of the
program.

> 
> 
> ‫في الأربعاء، 27 مارس 2024 في 2:31 ص تمت كتابة ما يلي بواسطة ‪Nada
> Elsayed‬‏ <‪nadaelsayed163@gmail.com‬‏>:‬
> 
> > Greetings All,
> > Hope this email finds you well.
> > I am interested in "Extend the plugin to add checking for usage of
> > the
> > CPython API" project. First of all, I built the library, and now I
> > am
> > trying to debug it. Then, I also used Cpython in 3 demos to
> > understand how
> > it works. Finally, I read the uploaded patch comments to understand
> > the
> > codebase and file structure.

As I mentioned above, please send me the demo code you wrote.

What timezone are you in?  (I'm in EDT, UTC+4)

Sorry again for now responding sooner, and if you haven't applied yet,
you should do that ASAP as it looks like the deadline is in 4 hours
time; prioritize getting that in over responding to my other questions.

Let me know if you need help with anything.

Thanks
Dave


> > 
> > I was wondering if you could review my suggested timeline?
> > suggested Timeline:
> > 
> >    -
> > 
> >    May 1-26:
> >    -
> > 
> >       Explore Cython modules, emphasizing entry-points and bug
> >       identification.
> >       -
> > 
> >       Study analyzers, particularly cpy-analyzer, to enhance
> >       understanding.
> >       -
> > 
> >       Debug the codebase to grasp its structure and potential areas
> > for
> >       improvement.
> >       -
> > 
> >       Focus investigation on "errors in GIL handling" and
> > "tp_traverse
> >       errors".
> >       -
> > 
> >    Weeks 1-6:
> >    -
> > 
> >       Investigate GIL (Global Interpreter Lock) errors extensively.
> >       -
> > 
> >       Engage in discussions and develop viable solutions to address
> >       identified issues.
> > 
> > 
> > 
> >    -
> > 
> >    Weeks 7-12:
> >    -
> > 
> >       Gain insight into the functioning of the Garbage Collector.
> >       -
> > 
> >       Implement checks to mitigate traverse errors effectively.
> >       -
> > 
> >       Ensure robust error handling mechanisms are in place through
> >       thorough study and practical implementation.
> > 
> >