Re: Getting the word to conventional programmers

[Christopher Nelson]

Hey, Jeff Hobbs got the last word. ;-)

-- 
http://mail.python.org/mailman/listinfo/python-list

PEP idea: Instrumented Python

[Christopher Nelson]

I was looking at adding dtrace-like dynamic tracing to Python.  Note that
this isn't dtrace itself.  The basic rationale:

1. A lot of enterprise-level software is written in Python.  It is difficult
to impossible to reproduce the customer environment in a test lab.
Sometimes applications hang mysteriously, and we are unable to duplicate the
problems in our environment.
2. dtrace is a good design.  It has little to no overhead for collection
points that are not collecting data.  Emulating that behavior allows you to
test what you fly and fly what you test.
3. Having the ability to only get trace data you want (or need) instead of
trace data for every instruction executed is very useful.  It also reduces
bandwidth requirements when archiving the traces, or shipping them out over
a network connection.
4. The ability to dynamically expand and contract the tracing scope during a
trace is vital to getting the right data.

The general plan would be to provide collectors in all of the public python
API functions.  The filtering code would also be in the local system, for
speed and bandwidth-conserving purposes.  The filters should generally be
native code.  The data should be writeable to a file or to a network
socket.  In addition, there should be a network socket listening for
commands from a tracing client.  The client would be able to upload
additional filter scripts and start or stop tracing transparently to the
running source.

For security there should be an authentication mechanism that allows the
application to decide whether or not a connection to the trace facility
should be allowed, and a way to disable the trace listening port on
startup.  (Or perhaps it should be disabled on startup by default and
enabled if so desired.)

Finally, there should, of course, be Pythonic access to the trace system.

The essential differences between the current tracing system and the
proposal involve the selectable granularity, the transparent remote access,
and automatic triggering of collection points.

Comments? Please make sure to reply to all, I am not subscribed to the list.

-={C}=-
-- 
http://mail.python.org/mailman/listinfo/python-list

Re: 404 not found on for Python 2.6 Itanium

[Christopher Nelson]

I'm not sure what to say about that.  The company I work for is
committed to Python (our product is mostly Python source), and my
current job is to make our software work on Itanium, which means
providing an Itanium build of Python.  As long as I have this job I
suspect that I will be maintaining it.  However, "maintaining" it for
us means that I deliver a set of binaries and build system
integration.  My buildsystem changes are a significant departure from
the way Python currently builds.

Since Python 2.6 actually supports a decent windows compiler, it may
be easier for me to provide the various platform binaries (assuming we
go to Python 2.6 in the next year or so) within the stock python build
framework. (Which mostly means patches that the community might
actually find useful.  My current build framework targets Python 2.4
on VS2K5, which is probably of little use to anyone.)

In any case, my concern with dropping a stock python itanium distro
involves the vastly diminished probability that others will provide
Itanium versions of, for example py2exe and pywin32.

 I would certainly be willing to help with testing and building and
bug fixing to the extent that my secular job allows it.

> We are fairly weak in the Windows area, and Martin is currently the
> person we rely on for these builds. If he can't support them, they don't
> get built.
>
> If you want to stand up for the task I don't imagine it would be too
> difficult to submit patches for the Itanium builds. You would need to
> convince people about your intention of providing long-term support,
> however.
--
http://mail.python.org/mailman/listinfo/python-list