Changes from 3.2.3 to 3.2.4
Fixed a possible double deallocation in the mxDateTime C API
import helper. Thanks to Daniele Varrazzo for reporting this.
Changes from 3.2.2 to 3.2.3
Fixed a possible segfault when using the .pydate(), .pydatetime()
and .pytime() methods. Thanks to Daniel Szoska for reporting
this.
Changes from 3.2.1 to 3.2.2
mxDateTime seconds rounding is now more careful to not show
60.00 or 61.00 as second value.
mxDateTime will now correctly work with numeric arrays (numpy)
again. Thanks to Christian Marquardt for reporting the problem.
mxDateTime's DateTimeFromAbsDateTime() now accepts leap second
values (86400.0 - <86401.0) as well. Thanks to Christian
Marquardt for reporting the problem.
mxDateTime range errors did not always format the wrong value.
Made mxDateTime compile again on Python 2.1 and 2.2.
Changes from 3.2.0 to 3.2.1
Fixed a segfault when comparing DateTime/DateTimeDelta with
None objects. Thanks to Mark Matthews for reporting this.
Changes from 3.1.2 to 3.2.0
Added new .rebuild() methods to both DateTime and DateTimeDelta
objects, making it easier creating new objects from existing
ones by just replacing some of the parameters (akin to the
mxURL .rebuild() method).
Greatly enhanced the interoperability with the Python datetime
module objects:
Added support for handling mixed type operations with
datetime.time objects.
Added new constructor methods to DateTime and DateTimeDelta
objects which aid in combining them with Python datetime
module objects: .pytime(), .pytimedelta(), .pydatetime()
and .pydate() as appropriate.
Added support for Python datetime module objects to the
generic mxDateTime constructors DateTimeFrom(), DateFrom(),
DateTimeDeltaFrom() (and their aliases).
The Python datetime module's C API is now loaded on demand
whenever mxDateTime needs to work with PyDateTime objects.
mxDateTime was updated to use mixed type number slots, a
feature which was added to Python in version 2.1 (by the
author of mxDateTime, Marc-André Lemburg). This has made
working with DateTime and DateTimeDelta objects and other
date/time types a lot more orbust.
mxDateTime's gmtime() now also works for ticks values beyond
2038 on 32-bit platforms that implement a POSIX confirm gmtime(),
but cannot handle post 2038 dates due to data type restrictions,
e.g. older 32-bit Linux platforms. As side-effect, this also
speeds up the gmtime() implementation on all platforms with
POSIX conform date/time handling.
mxDateTime will try to use the most accurate clock available
on the system for now(). For most POSIX systems, this is a
nanosecond resolution clock. A new global now_resolution allows
checking the resolution reported by the system. The performance
of now() was enhanced by directly interfacing to the various
platform C APIs.
Changed: mxDateTime will now format the seconds value in the
repr() and the str() output rounded to two decimal places. In
previous versions, it used to truncate the fraction after two
decimal places.
Known problem: mxDateTime doesn't build on FreeBSD with Python
2.7 and 2.7.1. This is a known problem with Python 2.7 and will
be fixed in Python 2.7.2. See http://bugs.python.org/issue10547
for details.
DateTimeFrom() now accepts a defaultdate parameter when parsing
strings or keyword-only arguments. defaultdate provides the
defaults to assume when pars of the date/time are not given.
It defaults to today().
DateFrom() will now only parse the date parts of a string and
only accept date-related keyword arguments.
Fixed a bug in the mxDateTime parser that triggered with some
ISO formats using second fractions. Thanks to Francesco
Pierfederici for bringing this to our attention.
Added support for more US AM/PM date formats such as "5:08pm"
(without space), "5:08 p.m." (with additional dots) to the
mxDateTime parser. Thanks to Tom at TicketStumbler for bringing
this to our attention.
Changed C API: mxDateTime now uses C longs for years internally
and in the C API. Note that the published C API has changed
because of this: mxDateTime.DateTime_FromDateAndTime() now
expects a long as year instead of an int. This change will
require a recompile of the applications using the mxDateTime
C API, but should only be noticeable on 64-bit platforms.
Added new C API DateTime_FromAbsDateTime to the mxDateTime C
API.
Added version number to C API object: Due to the changes in
the C API, the name of the C API object "mxDateTimeAPI" was
changed to "mxDateTimeAPI2", so that applications relying on
the old API don't import the changed API by accident.
Added optional calendar parameter to DateTimeFromAbsDateTime().
This allows creating DateTime instances with a given calendar.
Default is to use the Gregorian calendar.
Added BST to mx.DateTime.Timezone.
Fixed problem with now() resolution on Windows. It now provides
millisecond resolution again.
Fixed a bug in mx.DateTime.DateTimeFromAbsDateTime() which
caused an endless loop on 64-bit platforms for very large year
values.
Fixed Debian bug#494792: Incorrect subtraction with regular
Python datetime. This was actually a side-effect of the coercion
logic previously used in mxDateTime and not really a bug. The
new mixed type number slot implementations made it possible
to Darko Zurman for pointing this out.
Removed left-over debug code which caused the builtin strptime()
never to get used. Thanks to Alok Singhal for this one.
Fixed a bug in the mxDateTime .ticks() method which causes it
to raise an error for vahe Epoch.
This changes the buildlink3.mk files to use an include guard for the
recursive include. The use of BUILDLINK_DEPTH, BUILDLINK_DEPENDS,
BUILDLINK_PACKAGES and BUILDLINK_ORDER is handled by a single new
variable BUILDLINK_TREE. Each buildlink3.mk file adds a pair of
enter/exit marker, which can be used to reconstruct the tree and
to determine first level includes. Avoiding := for large variables
(BUILDLINK_ORDER) speeds up parse time as += has linear complexity.
The include guard reduces system time by avoiding reading files over and
over again. For complex packages this reduces both %user and %sys time to
half of the former time.
on some platforms that lacked shared library support in the past. The
list hasn't been maintained at all and the gain is very limited, so just
get rid of it.
- assume that Python 2.4 and 2.5 are compatible and allow checking for
fallout.
- remove PYTHON_VERSIONS_COMPATIBLE that are obsoleted by the 2.3+
default. Modify the others to deal with the removals.
and add a new helper target and script, "show-buildlink3", that outputs
a listing of the buildlink3.mk files included as well as the depth at
which they are included.
For example, "make show-buildlink3" in fonts/Xft2 displays:
zlib
fontconfig
iconv
zlib
freetype2
expat
freetype2
Xrender
renderproto
RECOMMENDED is removed. It becomes ABI_DEPENDS.
BUILDLINK_RECOMMENDED.foo becomes BUILDLINK_ABI_DEPENDS.foo.
BUILDLINK_DEPENDS.foo becomes BUILDLINK_API_DEPENDS.foo.
BUILDLINK_DEPENDS does not change.
IGNORE_RECOMMENDED (which defaulted to "no") becomes USE_ABI_DEPENDS
which defaults to "yes".
Added to obsolete.mk checking for IGNORE_RECOMMENDED.
I did not manually go through and fix any aesthetic tab/spacing issues.
I have tested the above patch on DragonFly building and packaging
subversion and pkglint and their many dependencies.
I have also tested USE_ABI_DEPENDS=no on my NetBSD workstation (where I
have used IGNORE_RECOMMENDED for a long time). I have been an active user
of IGNORE_RECOMMENDED since it was available.
As suggested, I removed the documentation sentences suggesting bumping for
"security" issues.
As discussed on tech-pkg.
I will commit to revbump, pkglint, pkg_install, createbuildlink separately.
Note that if you use wip, it will fail! I will commit to pkgsrc-wip
later (within day).
developer is officially maintaining the package.
The rationale for changing this from "tech-pkg" to "pkgsrc-users" is
that it implies that any user can try to maintain the package (by
submitting patches to the mailing list). Since the folks most likely
to care about the package are the folks that want to use it or are
already using it, this would leverage the energy of users who aren't
developers.
by moving the inclusion of buildlink3.mk files outside of the protected
region. This bug would be seen by users that have set PREFER_PKGSRC
or PREFER_NATIVE to non-default values.
BUILDLINK_PACKAGES should be ordered so that for any package in the
list, that package doesn't depend on any packages to the left of it
in the list. This ordering property is used to check for builtin
packages in the correct order. The problem was that including a
buildlink3.mk file for <pkg> correctly ensured that <pkg> was removed
from BUILDLINK_PACKAGES and appended to the end. However, since the
inclusion of any other buildlink3.mk files within that buildlink3.mk
was in a region that was protected against multiple inclusion, those
dependencies weren't also moved to the end of BUILDLINK_PACKAGES.
compatibility is maintained afaict, except an additional "mx" prefix
in the namespace
-make it a "distutils" pkg, so it works with Python-2.2.x
-license change - now freely redistibutable
extension Makefile fragments, because they really don't have anything to
do with the buildlink[12] frameworks. Change all the Makefiles that use
application.buildlink.mk and extension.buildlink.mk to use application.mk
and extension.mk instead.
