STINNER Victor victor.stin...@gmail.com added the comment:
The new patch, issue9079.diff exposes gettimeofday
as time.gettimeofday() returning (sec, usec) pair.
A tuple is not the preferred type for a timestamp: Python uses float and is not
going to use something different (the PEP 410 was
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
___
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Updated the patch to reflect recent datetimemodule.c renaming to
_datetimemodule.c. No other changes between issue9079b.diff and
issue9079c.diff. I am going to commit issue9079c.diff soon unless someone
wants more
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Committed issue9079c.diff as r83744. This commit does not provide
time.gettimeofday() and therefore does not close the issue.
--
keywords: -needs review, patch
stage: commit review - needs patch
Reid Kleckner r...@mit.edu added the comment:
pytime.h looks like it got pasted into the file twice. Other than that, it
looks good to me and the tests pass on OS X here.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
Brian Curtin cur...@acm.org added the comment:
issue9079a.diff doesn't compile on Windows - timeval isn't defined. You'd have
to include Winsock2.h [0]. Adding something like the following within the
HAVE_FTIME block would work...
#ifdef MS_WINDOWS
#include Winsock2.h
#endif
I don't currently
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Interesting. As far as I can tell, struct timeval should not be used unless
HAVE_GETTIMEOFDAY is defined:
+#ifdef HAVE_GETTIMEOFDAY
+typedef struct timeval _PyTime_timeval;
+#else
+typedef struct {
+time_t
Reid Kleckner r...@mit.edu added the comment:
I think you used 'struct timeval *' in the function definition instead of
'_PyTimeVal *'.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
Brian Curtin cur...@acm.org added the comment:
Here are the errors I get:
Error 104 error C2037: left of 'tv_sec' specifies undefined struct/union
'timeval'c:\python-dev\py3k\Python\pytime.c 46 pythoncore
Error 105 error C2037: left of 'tv_usec' specifies undefined
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I think Reid nailed the issue. Fix is coming.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
issue9079b.diff should fix the Windows issue.
--
Added file: http://bugs.python.org/file18108/issue9079b.diff
___
Python tracker rep...@bugs.python.org
Brian Curtin cur...@acm.org added the comment:
I won't have time to review this, but I can say issue9079b.diff works fine on
Windows.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
Reid Kleckner r...@mit.edu added the comment:
I think you forgot to svn add pytime.c before making the diff.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Indeed. Replacing issue9079a.diff now.
--
Added file: http://bugs.python.org/file18045/issue9079a.diff
___
Python tracker rep...@bugs.python.org
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file18034/issue9079a.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
OK, can someone show me an example of how functions defined in core Python can
be made available to extension modules? I thought I could model pytime.h/.c
after pymath.h/.c, but the later is not used in extension
Antoine Pitrou pit...@free.fr added the comment:
OK, can someone show me an example of how functions defined in core
Python can be made available to extension modules? I thought I could
model pytime.h/.c after pymath.h/.c, but the later is not used in
extension modules. I must be missing
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
No it must be something else. Attached issue9079-fail.diff fails with
Symbol not found: __PyTime_gettimeofday
Referenced from: .../build/lib.macosx-10.4-x86_64-3.2-pydebug/datetime.so
even though it is in pytime.o
$
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Added file: http://bugs.python.org/file18030/issue9079-fail.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
___
Antoine Pitrou pit...@free.fr added the comment:
Le vendredi 16 juillet 2010 à 19:51 +, Alexander Belopolsky a
écrit :
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
No it must be something else. Attached issue9079-fail.diff fails with
Here it fails earlier:
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Antoine,
you must be building on Windows. I'll try to guess where ftime is defined and
repost the patch.
--
___
Python tracker rep...@bugs.python.org
Georg Brandl ge...@python.org added the comment:
I'd like to help diagnose but I don't know what Erreur 1 means.
--
nosy: +georg.brandl
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I fixed the ftime issue (I hope), but the build still fails. I did not test on
Linux, but I tested on OSX with HAVE_FTIME. Replacing the failing patch.
--
Added file:
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file18030/issue9079-fail.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Removing spurious configure change from the fail patch.
--
Added file: http://bugs.python.org/file18032/issue9079-fail.diff
___
Python tracker rep...@bugs.python.org
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
Removed file: http://bugs.python.org/file18031/issue9079-fail.diff
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
___
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
It looks like my reluctance to add gettimeofday to core without using it there
was well founded. Simply adding a dummy call to _PyTime_gettimeofday in main()
fixed the build problem. This is a hack, of course, so I am
Antoine Pitrou pit...@free.fr added the comment:
It looks like my reluctance to add gettimeofday to core without using
it there was well founded. Simply adding a dummy call to
_PyTime_gettimeofday in main() fixed the build problem.
It's rather strange. I'm sure we have external API
Antoine Pitrou pit...@free.fr added the comment:
It looks like my reluctance to add gettimeofday to core without using
it there was well founded. Simply adding a dummy call to
_PyTime_gettimeofday in main() fixed the build problem.
It's rather strange. I'm sure we have external API
Mark Dickinson dicki...@gmail.com added the comment:
Hmm, after thinking about it, what happens is that the C object file is
not used at all, so it's probably optimized away by the linker.
That sounds right. I recall similar problems with pymath.c at one stage: none
of the functions it
Reid Kleckner r...@mit.edu added the comment:
Right, it's one of the peculiarities of archive files (I think). When none of
an object file's symbols are used from the main program, the object file is
dropped on the floor, ie not included. This has bizarre consequences in C++
with static
Antoine Pitrou pit...@free.fr added the comment:
Jeff Yasskin says you should create a noop function in your object
file and call it from PyMain for force linkage of the object file
you're building.
Indeed, something like _PyTime_Init().
I don't think Modules/python.c is a good place though,
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Reid,
I am leaning towards reverting to Plan A (issue9079.diff). Would your use case
be served well by a _time module exposing C API via a capsule? This what
datetime does currently.
--
Reid Kleckner r...@mit.edu added the comment:
I'd really rather not try to rely module loading from a threading primitive. :)
I think if you follow Antoine's suggestion of adding _PyTime_Init (which does
nothing in the body other than a comment) it should work fine.
--
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
It turns out I misunderstood how date.today() worked [1] and issue9079.diff
introduced significant change in behavior. Bringing timeofday into core rather
than _time.c also introduced several complications. As a result
Changes by Alexander Belopolsky belopol...@users.sourceforge.net:
--
nosy: +tim.golden
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
___
___
Antoine Pitrou pit...@free.fr added the comment:
Instead of being defined in _time.h, perhaps the new API function should be
provided by core Python? It would probably help in certain threading primitives.
--
nosy: +pitrou
___
Python tracker
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Mon, Jul 12, 2010 at 12:07 PM, Antoine Pitrou rep...@bugs.python.org wrote:
..
Instead of being defined in _time.h, perhaps the new API function should be
provided by core Python?
This is an interesting idea, but
Antoine Pitrou pit...@free.fr added the comment:
Instead of being defined in _time.h, perhaps the new API function should be
provided by core Python?
This is an interesting idea, but proposed Py_gettimeofday inherits
float_time logic of falling back on ftime and then plain time in case
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
On Mon, Jul 12, 2010 at 1:06 PM, Antoine Pitrou rep...@bugs.python.org wrote:
..
Indeed, the GIL code would probably still use its own code paths.
However, other less sensitive code could rely on the new API. For
Mark Dickinson dicki...@gmail.com added the comment:
Assigning back to Alexander; sorry I haven't had time to look at this.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
___
Changes by Mark Dickinson dicki...@gmail.com:
--
assignee: mark.dickinson - belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9079
___
___
Reid Kleckner r...@mit.edu added the comment:
The patch looks good to me FWIW.
I would be interested in using this perhaps in issue8844, which involves lock
timeouts. It may be true that the POSIX API uses nanoseconds, but pythreads
only exposes microsecond precision.
In order to use it
Mark Dickinson dicki...@gmail.com added the comment:
To keep things clean, would it be possible to separate this into two patches,
one containing the refactoring and one for the newly exposed gettimeofday?
--
___
Python tracker
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
The original patch, gettimeofday.diff was just refactoring. I unlinked it to
keep the file list clean, but it is still available:
http://bugs.python.org/file17766/gettimeofday.diff
I decided to expose
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
Mark,
I am reassigning this to you for commit review. I am changing the title to
reflect the visible part of the change. The datetime module gains direct
access to system gettimeofday at the C level while time module
Raymond Hettinger rhettin...@users.sourceforge.net added the comment:
It would be great if Tim Peters could be consulted about some of these ideas.
He put a great deal of thought into the API, what should be included and what
should be excluded.
--
nosy: +rhettinger
Alexander Belopolsky belopol...@users.sourceforge.net added the comment:
I would very much appreciate Tim's input on datetime issues. This particular
issue is fairly minor, but Tim's expertise will be invaluable for anything
timezone related. I do appreciate the incredible amount of
48 matches
Mail list logo
