was installed previously. This fixes bug #476904, but I'm not 100%
sure it doesn't break anything else. But if it does I'll notice tomorrow
when I try to build GRiNS:-)
Try to ensure that divmod(-0.0, 1.0) -> (-0.0, +0.0) across platforms.
It always did on Windows, and still does. It didn't on Linux. Alas,
there's no platform-independent way to write a test case for this.
Bugfix candidate.
presence of NaNs. So pass the issue on to the platform libm fabs();
after all, fabs() is a std C function because you can't implement it
correctly in portable C89.
should just avoid calling it in the first place to avoid waiting for a repr
of a large object like a dict or list. The result of PyObject_Repr() was
being leaked as well.
Bugfix candidate!
objects to save in gc.garbage. This should be the last change needed to
fix SF bug 477059: "__del__ on new classes vs. GC".
Note that this change slightly changes the behavior of the collector.
Before, if a cycle was found that contained instances with __del__
methods then all instance objects in that cycle were saved in
gc.garbage. Now, only objects with __del__ methods are saved in
gc.garbage.
if you are not building while logged in to the console (you cannot
connect to the window server, so the Carbon library doesn't initialize).
Added a quick hack to skip the import test, with a warning, for modules
linked against Carbon.
When moving objects with a __del__ attribute to a special list, look
for __del__ on new-style classes with the HEAPTYPE flag set as well.
(HEAPTYPE means the class was created by a class statement.)
routines. As of 10.1 using Carbon will crash Python if no window server is
available (ssh connection, console mode, MacOSX Server). This fixes bug
#466907.
A result of this mod is that the default 8bit encoding on OSX is now ASCII,
for the time being. Also, the extension modules that need the Carbon
framework now explicitly include it in setup.py.
Removed "#undef HAVE_HYPOT" line from Borland config, as suggested.
Whether this will break some other Borland usage is a good question I
can't answer.
LaTeX2HTML. This is not safe to do in general (for the reasons LaTeX2HTML
protects against dvips to begin with), but is safe if we do not actually
need to run dvips. Note that we also assume it is safe if the user
specifically requests PostScript generation. See the comments for further
explanation.
