What lies ahead; what lies beneath

[Edward K. Ream]

It's time for me to see what's next after Leo. I won't be happy not programming :-)

I am looking for an "impossible" project. That will get the creative juices flowing.

As a starting point, I envisage a tool that collects data about programs at runtime, and associates that data with corresponding Leo nodes. Python's pdb debugger (or Leo's SherlockTracer class) is an obvious starting point.

Similar thinking led me to study the coverage sources. Wow--the complexities that lie beneath coverage's simple interfaces!  I have just uploaded coverage.leo to leo-editor-contrib.

We recently discussed the role of comments and narratives in our programs. coverage has some of the best docstrings I've ever seen.  Two longish examples:

From the PyTracer class, in pytracer.py (right after the docstring):

   # Because of poor implementations of trace-function-manipulating tools,
    # the Python trace function must be kept very simple.  In particular, there
    # must be only one function ever set as the trace function, both through
    # sys.settrace, and as the return value from the trace function.  Put
    # another way, the trace function must always return itself.  It cannot
    # swap in other functions, or return None to avoid tracing a particular
    # frame.
    #
    # The trace manipulator that introduced this restriction is DecoratorTools,
    # which sets a trace function, and then later restores the pre-existing one
    # by calling sys.settrace with a function it found in the current frame.
    #
    # Systems that use DecoratorTools (or similar trace manipulations) must use
    # PyTracer to get accurate results.  The command-line --timid argument is
    # used to force the use of this tracer.

Notice how self-contained these comments are.

Here is another example, from encodings.py:

"""Imposter encodings module that installs a coverage-style tracer.

This is NOT the encodings module; it is an imposter that sets up tracing
instrumentation and then replaces itself with the real encodings module.

If the directory that holds this file is placed first in the PYTHONPATH when
using "coverage" to run Python's tests, then this file will become the very
first module imported by the internals of Python 3.  It installs a
coverage.py-compatible trace function that can watch Standard Library modules
execute from the very earliest stages of Python's own boot process.  This fixes
a problem with coverage.py - that it starts too late to trace the coverage of
many of the most fundamental modules in the Standard Library.
"""

Edward

[Edward K. Ream]

On Thu, Oct 20, 2022 at 7:59 AM Edward K. Ream <edre...@gmail.com> wrote:

It's time for me to see what's next after Leo. I won't be happy not programming :-)

I am looking for an "impossible" project. That will get the creative juices flowing.

I just found OpenAI Codex. I signed up, which took me to the overview.

Edward

[Edward K. Ream]

On Thursday, October 20, 2022 at 7:59:40 AM UTC-5 Edward K. Ream wrote:

It's time for me to see what's next after Leo. I won't be happy not programming :-)

My first thought was to create a tracer/debugger that would allow me to study python programs without modifying the source code. But this plan would be foolish. Debuggers slow down programs dramatically. Worse, debuggers operate at the statement level.

Instead, my usual strategy is to modify the source code to gather "interesting" data. This is perfectly safe, provided I use git to manage the sources!

So a more effective strategy is:

- Ask questions whose answers would provide insights.

- Add statements to help answer those questions.

- Be alert for bespoke tools to augment tracing statements.

- Repeat as necessary.

Those bespoke tools might create or reveal patterns, so look for new pattern-producing tools.

Edward

[Edward K. Ream]

On Thursday, October 20, 2022 at 7:59:40 AM UTC-5 Edward K. Ream wrote:

We recently discussed the role of comments and narratives in our programs. coverage has some of the best docstrings I've ever seen.  Two longish examples: [snip]

Notice the contingent and pragmatic nature of these (excellent!) comments:

- They depend on the actual code: they could not have been written beforehand.

- They are not part of a general narrative: they discuss low-level details or bugs.

Edward

[Thomas Passin]

And they are essential for understanding why the code is there and is the way it is.  I don't think reading the same code without the comments would let any normal person modify or rewrite the code without messing up the program's desired operation.

[Edward K. Ream]

On Fri, Oct 21, 2022 at 9:20 AM Thomas Passin <tbp1...@gmail.com> wrote:

Notice the contingent and pragmatic nature of these (excellent!) comments:

- They depend on the actual code: they could not have been written beforehand.

- They are not part of a general narrative: they discuss low-level details or bugs.

And they are essential for understanding why the code is there and is the way it is.  I don't think reading the same code without the comments would let any normal person modify or rewrite the code without messing up the program's desired operation.

Exactly. The comments are essential and contingent.

Edward