Changes to Leo inspired by stc

[Edward K. Ream]

Rev 5551 improves the SherlockTracer class in leoGlobals.py.  Better traces, and optional traces entry/exit from functions separately.

Rev 5553 allows g.trace and g.pr to work when leoGlobals.py is used in standalone mode (g.app is None).

Edward

[Edward K. Ream]

On Wednesday, January 9, 2013 4:56:37 PM UTC-6, Edward K. Ream wrote:

I think it would be useful for Leo to write, at the start of each external file, the name of the .leo file that wrote it.  This would be the short file name, x.leo, not the full path.  This is, imo, enough of a clue :-)  Sometimes that clue comes in handy: there are a surprisingly large number of .leo files on my drives, and I often don't remember which .leo file is responsible for creating the external file.  This clue is particularly valuable when I use Leo to study somebody else's code: there is then no obvious way to remember the name of the .leo file that created the Leo sentinels.

Your comments please.

> Rev 5553 allows g.trace and g.pr to work when leoGlobals.py is used in standalone mode (g.app is None).

More work is coming.  I would like to eliminate the hack of initially assigning g to a nullObject instance.  I understand that this hack makes life a tad easier for one or two plugins, but the present code depends on Leo itself to set the g var.  This seems wrong, and makes leoGlobals.py much less useable than it should be outside of Leo.

The latest revs to leoGlobals.py are a half-way measure: they remove the "g." prefix from the code for g.trace and g.pr and a few other helpers.  This is a general solution, but I don't actually want to remove all the "g." prefixes from leoGlobals.py because a) I automatically type g.trace and b) using g.trace allows me to set the trace flag.  If I were to change g.trace to trace, I would have to change trace to something like trace_flag.  So I want another way.

Ideally, I would like to eliminate the "functions from leoGlobals" section in codewise.py and have codewise import leo.core.leoGlobals, or maybe a copy of same.  It's surprisingly inconvenient to have two copies of the trace function in leoPy.leo.  Of course, it would be possible to define codewise.py in codewise.leo, and perhaps that is the better way.

Again, I welcome your comments.

Edward

P.S. I have identified the nitty-gritty problem that pylint solves and that clearly is the key to static type checking.  I've created a "laboratory" to study and simplify that code.  I expect to spend a week or two more on this phase of the static type checking project, and then, regardless of result, it will be time to turn back to Leo for at least a full month.

EKR

[Terry Brown]

On Thu, 10 Jan 2013 08:41:16 -0800 (PST)
"Edward K. Ream" <edre...@gmail.com> wrote:

> On Wednesday, January 9, 2013 4:56:37 PM UTC-6, Edward K. Ream wrote:
>
> I think it would be useful for Leo to write, at the start of each external
> file, the name of the .leo file that wrote it. This would be the short
> file name, x.leo, not the full path. This is, imo, enough of a clue :-)
> Sometimes that clue comes in handy: there are a surprisingly large number
> of .leo files on my drives, and I often don't remember which .leo file is
> responsible for creating the external file. This clue is particularly
> valuable when I use Leo to study somebody else's code: there is then no
> obvious way to remember the name of the .leo file that created the Leo
> sentinels.
>
> Your comments please.

So you're talking about adding metadata to the info. in the sentineled
file formats.

Downsides:
- more visual cruft to ignore in other editors
- backwards compatibility issues for earlier versions of Leo

Upsides:
- helpful when you're looking at a file outside of Leo, maybe

I don't think the visual cruft issue is a big deal, a) there's already
a lot of annoying visual cruft in other editors when looking at
sentineled files, so a bit more won't matter, and b) I don't use the
sentineled file formats anyway :-)

The backwards compatibility issue seems like a bigger deal, is someone
going to find they can't ready a @file node in 2013-01-03 Leo because
it was written in 2013-01-20 Leo? Is the upside enough to justify
this? Or can the current format include the info. with out breaking
read in older Leos?

Iff you do add it, I'd argue for adding a) the time of write as well,
and b) making sure the mechanism is extensible so other metadata can be
written in the future without backwards compatibility issues, if they
even exist now that is.

Cheers -Terry

[Matt Wilkie]

I think it would be useful for Leo to write, at the start of each external file, the name of the .leo file that wrote it.  This would be the short file name, x.leo, not the full path. 

+1! 

...with the proviso that occasionally I have more than .leo file pointing to the same external file. I'm okay with "he who saves last wins", that's how it is with everything else anyway. Just thought I'd mention it so it's noted.

cheers,

-matt

[Edward K. Ream]

On Wednesday, January 9, 2013 4:56:37 PM UTC-6, Edward K. Ream wrote:

Rev 5551 improves the SherlockTracer class in leoGlobals.py.  Better traces, and optional traces entry/exit from functions separately.

Recent revs, concluding with  rev 5567, add more features to tracing:

- Optionally show calling args and return args.
- The ability to enable traces by class name.  For example::

    '-.*AClassName.*' # Disables traces of all methods of the class
    '-.*AClassName::.*' # Disables traces of all methods except the ctor.

I plan no further work at present on the SherlockTracer class.  However, it would be possible to override this class to gather method-specific data as desired.  I have the feeling that this might be a way to explore code more fully. 

There is a tension here: on the one hand, substantial knowledge of any code is required in order to know what data to gather.  In this sense, subclasses would be more like documentation tools.  Otoh, we need all the help we can get exploring other people's code, so maybe an approach like this would be valuable.

Edward

[Edward K. Ream]

On Thursday, January 10, 2013 11:17:23 AM UTC-6, Terry wrote:

So you're talking about adding metadata to the info. in the sentineled
file formats.

Downsides:
  - more visual cruft to ignore in other editors
  - backwards compatibility issues for earlier versions of Leo

I'm just talking about adding a comment line near the top of the file.  There should be no compatibility problems with other versions of Leo.  The read code remains unchanged.  Otoh, the write code must be sure to write the comment line only once.

Edward