how do you unload a module so SWIG and C++ can recompile it
eric jones
I'm using SWIG to build some python interfaces under windows. Every time I
need to recompile my module, I have to exit my python session so that my
interface dll is released. Otherwise my compiler can't create the dll file
because python is using it.
Does anyone have any easy way to unload an interface so that python will
release the dll? This way I could keep the same python session running.
thanks,
eric
Gordon McMillan
Nope. Completely clearing all traces of an extension module from the
interpreter is highly problematic.
Instead, if you have lot's of stuff to set up before you begin poking
at your extension module, save them in a script, and execute the
script with the -i option. This will execute the script and then
leave you in an interactive session.
- Gordon
Alexander V. Voinov
> eric jones writes:
>
> > Does anyone have any easy way to unload an interface so that python
> > will release the dll? This way I could keep the same python session
> > running.
>
> Nope. Completely clearing all traces of an extension module from the
> interpreter is highly problematic.
>
> Instead, if you have lot's of stuff to set up before you begin poking
> at your extension module, save them in a script, and execute the
> script with the -i option. This will execute the script and then
> leave you in an interactive session.
>
> - Gordon
Has anybody written a module which would enable to quickly and
easily save the current interpreter state into a human readable/
editable script to be loaded in the future?
I think it should not be longer than two-three dozens of lines.
Because everything needed is available in Python in a very
legal way.
But it should be probably written by a Python expert.
Have I overlooked a standard module with the required
functionality? (A friend of marshall, pickle, etc)
Alexander
Tim Peters
> Has anybody written a module which would enable to quickly and
> easily save the current interpreter state into a human readable/
> editable script to be loaded in the future?
Not that I know of, and kinda doubt we'll see one this century <wink>. You
need to define "current interpreter state", though -- as I read it, it
includes such stuff as e.g. the collection of currently-open files and their
positions, etc, which means saving away & restoring arbitrary bits of stuff
in the platform's C libraries too. Even finding all the Python objects
currently alive is a chore not to be underestimated, and "doing something"
about them would at least require that all user-defined classes support a
protocol for saving & restoring (which relatively few actually do!).
attractive-goal-though-ly y'rs - tim
Christian Tismer
How about this:
The question was about PythonWin, and Eric wanted to be able to
repeat his session for testing. That is indeed much easier than
to save the interpreter state.
Let me look if I can get a session logger together quickly.
ciao - chris
--
Christian Tismer :^) <mailto:tis...@appliedbiometrics.com>
Applied Biometrics GmbH : Have a break! Take a ride on Python's
Kaiserin-Augusta-Allee 101 : *Starship* http://starship.skyport.net
10553 Berlin : PGP key -> http://pgp.ai.mit.edu/
we're tired of banana software - shipped green, ripens at home
Christian Tismer
>
> > ...
> > Has anybody written a module which would enable to quickly and
> > easily save the current interpreter state into a human readable/
> > editable script to be loaded in the future?
>
> Not that I know of, and kinda doubt we'll see one this century <wink>.
> attractive-goal-though-ly y'rs - tim
Now, I tried a little macro-recorder for pythonWin.
Works so far, although there can be much improvement.
I'd be very interested in what people think about it.
ciao - chris
pywinlog.py
-------------------------------------------------------------------------------
"""
pywinlog.py
Macro recorder for pythonWin
C. Tismer - 981018
The idea:
PythonWin does a lot of checks until it finds out what it has
to execute finally. But it ends up by calling the builtin
function compile and checks if it works.
We intercept compile to grab it's string arguments and
to collect them in a list.
This gives exactly all the lines which were syntactically
correct.
Usage:
>>> from pywinlog import logger
switches the logger on by default, and logs into an internal list.
logger methods:
on() starts logging.
off() stops logging.
clear() wipes the log out
save(filename) appends the current buffer to the file
file(filename) starts fail-safe logging
lock() inhibit logger comands
unlock() re-enable logger commands
replay() an attempt to replay a session
load(filename) loading a session for replay
On fail-safe logging:
The log file is opened and closed for every command.
This can be useful if you are trying code which is
likely to kill PythonWin.
On running a log script:
In order to re-execute the logging commands,
the log file is started with a logger.lock() which prevends
any further log action.
lock() and unlock() disable the whole class.
"""
__version__ = (0, 0, 1)
import pywin.framework.interact, string, sys
_patched_module = pywin.framework.interact
_patched_class = _patched_module.InteractiveCore
class session_log_class:
try:
_old_compile = _patched_module.compile
except AttributeError:
_old_compile = compile
# inhibitor
_locked = 0
def _new_compile(self, string, filename, kind):
ret = self._old_compile(string, filename, kind)
# no error handling needed. If compile breaks,
# we just don't get an entry - perfect!
# just avoid duplicates:
if not (kind=="eval" and self._kind=="exec" and
string==self._last):
self.append(string+"\n")
self._kind = kind
self._last = string
return ret
def __init__(self, filename=None):
self.lines = []
self.filename = filename
self._kind = ''
self._last = ''
self.active = 0
def append(self, str):
if self._locked: return self.inhibit()
if self.filename:
self.append_to_file(str, self.filename)
else:
self.lines.append(str)
def off(self, msg=None):
if self._locked: return self.inhibit()
if not self.active: return
self.append("from pywinlog import logger;logger.unlock()\n\n")
_patched_module.compile = self._old_compile
self.active = 0
if msg:
sys.stderr.write(msg+"\n")
def on(self):
if self._locked: return self.inhibit()
if self.active: return
self.append("from pywinlog import logger;logger.lock()\n\n")
_patched_module.compile = self._new_compile
self.active = 1
def clear(self):
if self._locked: return self.inhibit()
self.lines = []
def file(self, filename=None):
if self._locked: return self.inhibit()
self.filename = filename
self.on()
if filename:
self.save(filename)
def save(self, filename):
if self._locked: return self.inhibit()
txt = string.join(self.lines, "")
self.append_to_file(txt, filename)
self.clear()
def append_to_file(self, str, filename):
if self._locked: return self.inhibit()
# fail-safe method, will always open and close file
if filename:
try:
f=open(filename, "a")
f.write(str)
f.close()
except:
import sys
sys.stderr.write("*** Error writing to %s - logger
stopped\n" \
% filename)
self.off()
def lock(self):
self.__class__._locked = self.__class__._locked + 1
def unlock(self):
if self.__class__._locked > 0:
self.__class__._locked = self.__class__._locked - 1
def inhibit(self):
try:
raise "dummy"
except:
import sys
x=sys.exc_traceback
sys.stderr.write("#inhibited - logger.%s\n" \
% x.tb_frame.f_back.f_code.co_name)
def __del__(self):
if self.filename and not self._locked:
self.off()
def __repr__(self):
res = "pywinlog.logger - %s" % ["off", "active"][self.active]
if self.filename: res = res + " -> " + self.filename
if self._locked:
import sys
res=res + "# currently, the logger is locked(%d). To unlock,
send:\n" \
% self.__class__._locked
res = res + sys.ps1 + "logger.unlock()"
return res
def replay(self):
if self._locked: return self.inhibit()
self.off("-- logger turned off --")
ps1 = sys.ps1
ps2 = sys.ps2
try:
self.lock()
for cmd in self.lines:
cmd = string.strip(cmd)
lis = string.split(cmd, "\n")
print ps1+lis[0]
for more in lis[1:]:
print ps2+more
cmd = cmd + "\n"
codeObj = compile(cmd,'<interactive input>','exec')
try:
# mostly copied from interact.py:
import __main__
globs =__main__.__dict__
locs = globs
codeObj = compile(cmd,'<interactive input>','eval')
# worked - eval it
ret = eval(codeObj, globs, locs)
if ret is not None:
print repr(ret)
except SyntaxError: # means bad syntax for eval, but
exec is OK
exec codeObj in globs, locs
finally:
self.unlock()
def load(self, filename):
if self._locked: return self.inhibit()
self.off("-- logger turned off --")
lines = open(filename).read()
lines = string.split(lines, "\n\n")
self.lines = map(lambda s:s+"\n", lines)
logger = session_log_class()
logger.on()
print `logger`
-------------------------------------------------------------------------------
p.s.:
A logging file can be open in PyWin at the same time as it is written.
By switching to its window, it is updated.
A.Voinov
> > Has anybody written a module which would enable to quickly and
> > easily save the current interpreter state into a human readable/
> > editable script to be loaded in the future?
>
> need to define "current interpreter state", though -- as I read it, it
> includes such stuff as e.g. the collection of currently-open files and their
> positions, etc, which means saving away & restoring arbitrary bits of stuff
> in the platform's C libraries too. Even finding all the Python objects
> currently alive is a chore not to be underestimated, and "doing something"
> about them would at least require that all user-defined classes support a
> protocol for saving & restoring (which relatively few actually do!).
>
It doesn't seem to require to be such complicated.
For example, many Prolog implementations provide save/restore pair.
I do not remember details, but in most of them one could say:
? -
open(H, "my_file.txt"), % get a file handle
assert(my_silly_predicate(H)), % record it into the program database
save. % save the database
But this is useless, and I do not expect that any of Prolog implementation
takes care of that.
Moreover, if a Prolog implementation provided C extension interface,
one could expose pointers etc to Prolog as integer numbers (or strings).
Evidently, this all is for user's responsibility.
In the case of Prolog, however, it is much more easier to define
what should be saved.
Another Prolog feature: Predicate 'listing' usually dumps database in
a text form such that it could be imported later ("consulted"). This
has, as one sees, straightforward analog in Python.
So, one could speak about a reasonable subset of currents interpreter
state (contents) and let user be aware of that while saving/restoring.
Alexander
Tim Peters
[A.Voinov]
> It doesn't seem to require to be such complicated.
>
> For example, many Prolog implementations provide save/restore pair.
> I do not remember details, but in most of them one could say:
>
> ? -
> open(H, "my_file.txt"), % get a file handle
> assert(my_silly_predicate(H)), % record it into the
> program database
> save. % save the database
>
> But this is useless, and I do not expect that any of Prolog
> implementation takes care of that. Moreover, if a Prolog
> implementation provided C extension interface, one could expose
> pointers etc to Prolog as integer numbers (or strings).
> Evidently, this all is for user's responsibility.
>
> In the case of Prolog, however, it is much more easier to define
> what should be saved.
> ...
Indeed yes. Saving/restoring interpeter state is very much easier in some
other languages (especially those sprouted off the functional branch of the
language tree) for two reasons: they're self-contained worlds, and they
already have code written to find all live objects (part of their
garbage-collection schemes).
Now I forgot what this thread was about <0.3 wink>.
save-only-memory-ly y'rs - tim