Andi Vajda wrote:
> Actually, I tried to replace -nodefault with
-nodefaultctor and rebuild all
> with swig 1.3.28 and the destructor code was generated
and these warnings
> didn't appear anymore.
Yes, that now matches with my experience. Or at least,
while in some
tests I'm still seeing some incremental growth, barring
much more
strenuous testing, it feels well within what just some
normal working
set slush might be.
> Indeed. Apart from probably not rebuilding it
correctly, you didn't
> do anything wrong. I, however, did something completely
wrong by
> using -nodefault when what I really wanted was
-nodefaultctor, that
> is, no constructor code generation by default, only
generate code
> for constructors that I declare.
Which was the missing link for me. I wasn't sure why
-nodefault had been
chosen so wasn't sure what to change.
> So, apparently, the fix to this is simple:
>
> - use -nodefaultctor instead of -nodefault
> - and use swig 1.3.28 since -nodefaultctor doesn't
appear to be supported
> with swig 1.3.24
I think so yes. I did find the news for swig 1.3.28 as
adding this finer
grained constructor/destructor control to help avoid these
kinds of memory
leaks, so it looks like a nice confluence of events.
> I haven't done any other testing of PyICU with swig
1.3.28 and would
> appreciate it if you could report back about how it is
working for you.
> Every swig upgrade introduces a dose of unknowns...
So far other than the memory issue I've had no real
problems, but I'm
just in an "investigation" mode so may not give
it real heavy use in
the near term. The only other issues I think are more ICU
than the
wrapper (such as how to detect if creating a locale-aware
object such
as NumberFormat is given a locale for which it has no data).
About the only thing that I would find nice is if PyICU
could continue
to support building for Python 2.3, since a number of our
systems are
still using it. Handling the lack of Py_RETURN_NONE seems
easy enough
(just define it if not present), but the lack of a datetime
object in
the C layer might be a little more insurmountable or at
least
impractical. Even if the code just skipped supportinga such
a return
value when compiled for 2.3, it would be a little more
convenient for
building without needing local modification.
-- David
_______________________________________________
pyicu-dev mailing list
pyicu-dev osafoundation.org
http://lists.osafoundation.org/cgi-bin/mailman/
listinfo/pyicu-dev
|