Steve Dower added the comment:
Finally got back to looking at this, and since %f works against MSVC 14.0 I'm
just going to remove the part of the test that is currently failing and close
this issue.
--
___
Python tracker rep...@bugs.python.org
Roundup Robot added the comment:
New changeset 2c10e9f62613 by Steve Dower in branch '3.5':
Closes #24244: Removes invalid test from test_time
https://hg.python.org/cpython/rev/2c10e9f62613
New changeset f0ca1fabb41f by Steve Dower in branch 'default':
Closes #24244: Removes invalid test from
Yury Selivanov added the comment:
But why was it building just fine before this commit? I haven't updated my
system packages in a while.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
Steve Dower added the comment:
Those macros are only included if Py_BUILD_CORE is defined, regardless of
platform (see Include/pyport.h).
Is it possible that's being undefined somehow?
--
___
Python tracker rep...@bugs.python.org
Steve Dower added the comment:
Looking at a `grep PY_CORE_CFLAGS`, that sounds reasonable to me.
I assumed that all core files were already being compiled with Py_BUILD_CORE
(they certainly are for Windows), so this seems to be an oversight for
timemodule.c.
--
Ned Deily added the comment:
I think you have a Python installed in /usr/local that is interfering.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
___
Yury Selivanov added the comment:
Wild guess: perhaps you did a ./configure or the Makefile did an implicit
call to configure recently and/or you did a make install (to /usr/local)
before?
I don't have 'python' in /usr/local and /usr/local/bin
--
Ned Deily added the comment:
But do you have any Python header files in /usr/local/include? The gcc command
you pasted shows -I/usr/local/include? Mine don't show that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
Yury Selivanov added the comment:
yury@ysmac ~/dev/py/cpython (HG: default?) $ ls /usr/local/include/
librtmp osxfuse pycairo
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
___
Yury Selivanov added the comment:
FWIW, I think that in order to use _Py_BEGIN_SUPPRESS_IPH timemodule.c should
be compiled with PY_CORE_CFLAGS, and that should be reflected in the Makefile.
--
___
Python tracker rep...@bugs.python.org
Ned Deily added the comment:
Yury, I'm not seeing that compile error with current head of default on OS X.
Try a clean build, perhaps?
--
nosy: +ned.deily
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
Yury Selivanov added the comment:
This exact sequence of commands
$ make clean
$ ./configure
$ make -j8
does not build.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
___
Yury Selivanov added the comment:
$ hg status
shows nothing, branch is default (but 3.5 doesn't get built either) etc.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
___
Ned Deily added the comment:
Wild guess: perhaps you did a ./configure or the Makefile did an implicit call
to configure recently and/or you did a make install (to /usr/local) before?
--
___
Python tracker rep...@bugs.python.org
Yury Selivanov added the comment:
timemodule.c no longer compiles on MacOSX:
gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -DNDEBUG -g -fwrapv
-O3 -Wall -Wstrict-prototypes -Werror=declaration-after-statement -I./Include
-I. -IInclude -I/usr/local/include
Steve Dower added the comment:
That change was in for beta 1, so we would have noticed if we didn't get Mac
builds.
Something else has changed, probably some headers.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
Yury Selivanov added the comment:
Towards the end of the configured top-level Makefile, you should see:
Yes, I don't see that line. What should I do to regenerate it? And another
question: what did go wrong with my checkout?
--
___
Python
Majeed Arni added the comment:
Though %f is a valid format from Python's doc
https://docs.python.org/2/library/datetime.html, the fix just ignores it on
Windows? can we atleast get milliseconds on Windows and Micro on Linux?
%f Microsecond as a decimal number, zero-padded on the left.
Ned Deily added the comment:
Yury, another (less) wild guess: do you have an out-of-date Modules/Setup or
Setup.local? timemodule is defined in Setup.dist but that will be overridden
by a locally modified copy in the Modules directory. Towards the end of the
configured top-level Makefile,
R. David Murray added the comment:
Note that when I run into build problems after an update, I generally run 'make
distclean' and then redo the configure/make. This generally cleans up any
problems like this (and I don't find that I need to do it very often.)
--
Ned Deily added the comment:
So you did, sorry! Another, perhaps evan more reliable option is (requires
enabling the purge extension in hg):
hg purge --all
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
Ned Deily added the comment:
Check the times and contents on all of your Modules/Setup* files. Try deleting
Setup.local for one.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
___
Yury Selivanov added the comment:
Check the times and contents on all of your Modules/Setup* files. Try
deleting Setup.local for one.
I just made a clean checkout and that helped. I have no idea what caused this.
Thank you, Ned, for troubleshooting this with me!
--
priority:
Ned Deily added the comment:
Note that when I run into build problems after an update, I generally
run 'make distclean' and then redo the configure/make.
Yes, but I believe that won't help with changed Modules/Setup* files and,
because it is needed in the core interpreter executable,
Yury Selivanov added the comment:
Steve, maybe you can surround _Py_BEGIN_SUPPRESS_IPH with #ifdef
Py_BUILD_CORE?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
___
R. David Murray added the comment:
Right, that's why I said make *dist*clean. That does delete any existing Setup
file(s), which is what you want when working with a checkout for Python
development purposes.
--
___
Python tracker
Steve Dower added the comment:
When do we build timemodule.c outside of core?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
___
___
Roundup Robot added the comment:
New changeset 254b8e68959e by Steve Dower in branch 'default':
Issue 24244: Prevents termination when an invalid format string is encountered
on Windows.
https://hg.python.org/cpython/rev/254b8e68959e
--
nosy: +python-dev
Steve Dower added the comment:
That handles Python 3.5 and future versions, even if the supported formats
change.
Is there something that needs fixing in 3.4? I don't get a crash, just the
ValueError...
--
___
Python tracker rep...@bugs.python.org
R. David Murray added the comment:
So, this is expected behavior on Windows. I'm inclined to close the issue as
not a bug unless the Windows folks think eryksun suggestion is worth
considering. (If the error is suppressed, does windows fill in the rest of the
values and just leave the %f in
eryksun added the comment:
If the error is suppressed, does windows fill in the rest of
the values and just leave the %f in the string?
No, it does not. I understand now why ValueError was an intentional choice
here. The CRT actually breaks the loop with a goto if any call to expand_time
Steve Dower added the comment:
_Py_*_SUPPRESS_IPH is the right thing to use here. It still displays an
assertion dialog in debug builds, but ignoring it has the correct effect.
Patch attached for 3.5
--
keywords: +patch
Added file: http://bugs.python.org/file39438/24244_1.patch
R. David Murray added the comment:
OK. What made me wonder is that I saw that the 'invalid format string'
exception was removed by the patch...I guess that is also raised at a higher
level in the code.
--
___
Python tracker rep...@bugs.python.org
Steve Dower added the comment:
It raises ValueError just like now (no visible change), but it won't crash and
doesn't require being able to validate the complete format string.
If we want any different behaviour, we need to reimplement strftime for Python,
which I'd be okay with, but I'm not
Steve Dower added the comment:
It's raised by the existing handling for EINVAL at the end of the function.
Previously we'd crash before getting that far because of the invalid parameter
handler.
--
___
Python tracker rep...@bugs.python.org
R. David Murray added the comment:
What's the behavior after this patch? Does it just return the string
unmodified? Or return a null string? Or is the traceback generated at a
higher level (and if so what is the error message?)
--
___
Python
Changes by eryksun eryk...@gmail.com:
--
components: +Windows
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24244
___
___
Python-bugs-list mailing
37 matches
Mail list logo
