Re: Python3 work [was: The run up to Subversion 1.13.0]
On 2019/09/19 8:21, Johan Corveleyn wrote:
On Wed, Sep 18, 2019 at 12:08 PM Branko Čibej wrote:
On 18.09.2019 09:20, Johan Corveleyn wrote:
On Wed, Sep 18, 2019 at 5:36 AM Branko Čibej wrote:
On 18.09.2019 02:48, Johan Corveleyn wrote:
[[[
c:\python37\include\pytime.h(123): error C4115: 'timeval': named type
definition in parentheses
[C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj]
]]]
That makes no sense, my copy of pytime.h on Windows for Python 3.7.4 has
this on line 123:
PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv);
Looks like perfectly valid C to me. So we'll need a bit more context to
see where the actual error is coming from.
Not at my pc right now (I'll check again tonight), but from memory: I
think my copy of pytime.h looks the same. Line 123 seems to be the
first usage of 'timeval' though ... Is it possible that some include
is missing, so there is no declaration of the timeval struct type?
You do *not* need a definition of 'struct foo' in order to use a 'struct
foo*' pointer. So, no, that's not the problem.
Actually C4115 is only a warning.
https://docs.microsoft.com/cpp/error-messages/compiler-warnings/compiler-warning-levels-1-and-4-c4115?view=vs-2019
However, it seems we are treating it as an error by specifyinging build
option in build/generator/templates/vcnet_vcxproj.ezt .
(Is it related to https://bugs.python.org/issue25878, especially
msg256496 ?)
In other news, building the swig-py3 branch (after sync-merge from
trunk) with Python 2.7.16 (and swig 3.0.12) was successful.
Running the testsuite gives some failures though:
[[[
Testing Release configuration on local repository.
-- Running Swig Python tests --
..s..EEFF...
..
==
ERROR: test_conflict (client.SubversionClientTestCase)
Test conflict api.
--
Traceback (most recent call last):
File
"C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
line 593, in test_conflict
conflict = client.conflict_get(trunk_path, self.client_ctx, pool)
File "R:\test_release--swigpython\swig\pylib\libsvn\client.py", line
1642, in svn_client_conflict_get
return _client.svn_client_conflict_get(*args)
SubversionException: 155007 - 'R:\temp\tmpyeizeh-conflict\trunk' is
not a working copy
==
ERROR: test_conflict (client.SubversionClientTestCase)
Test conflict api.
--
Traceback (most recent call last):
File
"C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
line 94, in tearDown
self.temper.cleanup()
File
"C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\utils.py",
line 44, in cleanup
clean_func(target)
File "R:\test_release--swigpython\swig\pylib\libsvn\core.py", line
8453, in svn_io_remove_dir
return _core.svn_io_remove_dir(*args)
SubversionException: 720032 - Can't remove
'R:\temp\tmpyeizeh-conflict\.svn\wc.db'
720032 - Can't remove file 'R:\temp\tmpyeizeh-conflict\.svn\wc.db':
The process cannot access the file because it is being used by another
process.
==
FAIL: test_merge_peg3 (client.SubversionClientTestCase)
Test svn_client_merge_peg3.
--
Traceback (most recent call last):
File
"C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
line 442, in test_merge_peg3
self.assertEqual(readme_text, b'This is a test.\n')
AssertionError: 'This is a test.\r\n' != 'This is a test.\n'
==
FAIL: test_shelf (client.SubversionClientTestCase)
Test shelf api.
--
Traceback (most recent call last):
File
"C:\research\svn\dev\swig-py3\subversion\bindings\swig\python\tests\client.py",
line 644, in test_shelf
self.assertIn(new_subpath, statused_paths)
AssertionError: 'trunk\\new-shelf-test.txt' not found in
['trunk/new-shelf-test.txt', 'trunk/new-shelf-test.txt', None]
--
Ran 153 tests in 38.984s
FAILED (failures=2, errors=2, skipped=1)
Exception svn.core.SubversionException: SubversionException("Can't
open file 'R:\\temp\\tmp9ubdal-client\\db\\fs-type':
The system cannot find the path specified. ", 720003) in > ignored
[Test runner reported failure]
]]]
(Running the swig-python tests on trunk, with Python 2.7.16, was fully
successful)
The FAIL on test_merge_peg3 is a newline style issue on rea
Re: Python3 work [was: The run up to Subversion 1.13.0]
On Wed, Sep 18, 2019 at 12:08 PM Branko Čibej wrote: > > On 18.09.2019 09:20, Johan Corveleyn wrote: > > On Wed, Sep 18, 2019 at 5:36 AM Branko Čibej wrote: > >> On 18.09.2019 02:48, Johan Corveleyn wrote: > >>> On Mon, Sep 2, 2019 at 11:45 AM Julian Foad wrote: > > Troy Curtis Jr wrote: > >> James McCoy wrote: > >>> Finishing(?) and merging the Python3 support would be ideal. That > >>> would > >>> give one release for broader feedback before being in an LTS release. > >> It needs to get reintegrated with trunk again with the latest changes, > >> but the linux side of the house was looking good. It was in trying to > >> get my Windows Dev environment back up and running again that got me > >> frustrated and gave me an excuse to wander off doing other things... > >> IIRC, there is a build issue with the Py2 bindings in that branch on > >> Windows, but I never got far enough to check it out. > >> If there was someone who could help out on the Windows side, I can > >> jump in and get the branch up to trunk and retested in order to get > >> this thing over the finish line. > Johan Corveleyn wrote: > > I might be able to devote some time to this in the coming week(s), if > > you can tell me what I need to do / test / validate / ... :-). > Until Troy says something more specific, if you could switch to the > branch, catch-up merge from trunk, and see how much works on Py3 and on > Py2, that would be helpful. > >>> I'm sorry I missed the 1.13.x-branch deadline, but I finally got > >>> around to playing with the swig-py3 branch on Windows. > >>> Downloaded the latest Python release: 3.7.4. And using swig 3.0.12. > >>> > >>> Of course I didn't reread INSTALL, so I first ran into: > >>> > >>> [[[ > >>> WARNING: "C:\research\svn\dev\swig-py3\py3c\include\py3c.h" not found > >>> Use "--with-py3c" to configure py3c location. > >>> ]]] > >>> > >>> No problem, after downloading py3c from Github, and adding > >>> --with-py3c, I can start building it. > >>> > >>> However, I ran into the following error: > >>> > >>> [[[ > >>> c:\python37\include\pytime.h(123): error C4115: 'timeval': named type > >>> definition in parentheses > >>> [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj] > >>> ]]] > >> That makes no sense, my copy of pytime.h on Windows for Python 3.7.4 has > >> this on line 123: > >> > >> PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv); > >> > >> > >> Looks like perfectly valid C to me. So we'll need a bit more context to > >> see where the actual error is coming from. > > Not at my pc right now (I'll check again tonight), but from memory: I > > think my copy of pytime.h looks the same. Line 123 seems to be the > > first usage of 'timeval' though ... Is it possible that some include > > is missing, so there is no declaration of the timeval struct type? > > > You do *not* need a definition of 'struct foo' in order to use a 'struct > foo*' pointer. So, no, that's not the problem. Hmm, okay, just tried again ... same problem. Here is some more output: [[[ C:\research\svn\dev\swig-py3> msbuild subversion_vcnet.sln /nologo /v:q /p:Configuration=release /t:__SWIG_PYTHON__ c:\python37\include\pytime.h(123): error C4115: 'timeval': named type definition in parentheses [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj] C:\research\svn\dev\swig-py3\subversion\bindings\swig\proxy\swig_python_external_runtime.swg(2459): warning C4459: declaration of 'swig_this' hides global declaration [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj] C:\research\svn\dev\swig-py3\subversion\bindings\swig\proxy\swig_python_external_runtime.swg(2534): warning C4459: declaration of 'swig_this' hides global declaration [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj] ..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(2363): warning C4101: 'tmp': unreferenced local variable [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj] ..\..\..\subversion\bindings\swig\python\libsvn_swig_py\swigutil_py.c(2772): warning C4018: '>': signed/unsigned mismatch [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj] ]]] I tried with both the x86-64 and the x86 builds of Python 3.7.4 ... same result. Weird. I'm continuing to investigate. In other news, building the swig-py3 branch (after sync-merge from trunk) with Python 2.7.16 (and swig 3.0.12) was successful. Running the testsuite gives some failures though: [[[ Testing Release configuration on local repository. -- Running Swig Python tests -- ..s..EEFF... .. == ERROR: test_conflict (client.SubversionC
Re: svn commit: r1867063 - /subversion/site/staging/docs/community-guide/releasing.part.html
Julian Foad wrote on Wed, 18 Sep 2019 10:01 +00:00: > Daniel Shahaf wrote: > > However, as written, this change could be taken as saying that the rule > > of "one +1 and one +0" does not apply to bindings changes to non-LTS > > lines. (It's not clear whether the "preceded by a bold paragraph" unary > > operator has a higher or lower precedence than the binary "paragraph > > juxtaposition" operator.) Clarify, please? > > Thanks for your precision, again! Does http://svn.apache.org/r1867110 > sufficiently clarify the ambiguity? It certainly does. Thanks!
Re: Python3 work [was: The run up to Subversion 1.13.0]
On 18.09.2019 09:20, Johan Corveleyn wrote: > On Wed, Sep 18, 2019 at 5:36 AM Branko Čibej wrote: >> On 18.09.2019 02:48, Johan Corveleyn wrote: >>> On Mon, Sep 2, 2019 at 11:45 AM Julian Foad wrote: > Troy Curtis Jr wrote: >> James McCoy wrote: >>> Finishing(?) and merging the Python3 support would be ideal. That would >>> give one release for broader feedback before being in an LTS release. >> It needs to get reintegrated with trunk again with the latest changes, >> but the linux side of the house was looking good. It was in trying to >> get my Windows Dev environment back up and running again that got me >> frustrated and gave me an excuse to wander off doing other things... >> IIRC, there is a build issue with the Py2 bindings in that branch on >> Windows, but I never got far enough to check it out. >> If there was someone who could help out on the Windows side, I can jump >> in and get the branch up to trunk and retested in order to get this >> thing over the finish line. Johan Corveleyn wrote: > I might be able to devote some time to this in the coming week(s), if > you can tell me what I need to do / test / validate / ... :-). Until Troy says something more specific, if you could switch to the branch, catch-up merge from trunk, and see how much works on Py3 and on Py2, that would be helpful. >>> I'm sorry I missed the 1.13.x-branch deadline, but I finally got >>> around to playing with the swig-py3 branch on Windows. >>> Downloaded the latest Python release: 3.7.4. And using swig 3.0.12. >>> >>> Of course I didn't reread INSTALL, so I first ran into: >>> >>> [[[ >>> WARNING: "C:\research\svn\dev\swig-py3\py3c\include\py3c.h" not found >>> Use "--with-py3c" to configure py3c location. >>> ]]] >>> >>> No problem, after downloading py3c from Github, and adding >>> --with-py3c, I can start building it. >>> >>> However, I ran into the following error: >>> >>> [[[ >>> c:\python37\include\pytime.h(123): error C4115: 'timeval': named type >>> definition in parentheses >>> [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj] >>> ]]] >> That makes no sense, my copy of pytime.h on Windows for Python 3.7.4 has >> this on line 123: >> >> PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv); >> >> >> Looks like perfectly valid C to me. So we'll need a bit more context to >> see where the actual error is coming from. > Not at my pc right now (I'll check again tonight), but from memory: I > think my copy of pytime.h looks the same. Line 123 seems to be the > first usage of 'timeval' though ... Is it possible that some include > is missing, so there is no declaration of the timeval struct type? You do *not* need a definition of 'struct foo' in order to use a 'struct foo*' pointer. So, no, that's not the problem. -- Brane
Re: svn commit: r1867063 - /subversion/site/staging/docs/community-guide/releasing.part.html
Daniel Shahaf wrote: My reading of consensus is that we changed "three +1s" to "two +1s" for non-LTS lines, but didn't _increase_ the bar in any way. Agreed. However, as written, this change could be taken as saying that the rule of "one +1 and one +0" does not apply to bindings changes to non-LTS lines. (It's not clear whether the "preceded by a bold paragraph" unary operator has a higher or lower precedence than the binary "paragraph juxtaposition" operator.) Clarify, please? Thanks for your precision, again! Does http://svn.apache.org/r1867110 sufficiently clarify the ambiguity? - Julian
Re: Change to Subversion PMC rule for approving backports
+1 Thanks Julian! On Tue, Sep 17, 2019 at 5:11 PM Branko Čibej wrote: > On 17.09.2019 16:53, Julian Foad wrote: > > Bert Huijben wrote: > > +1 on reducing the number of required votes to just 2 +1s. > > > > We have consensus in this thread for reducing the requirement for > > regular (non-LTS) releases to two "+1" votes, but not to just one. > > Thanks for pushing this through, Julian. > > -- Brane > >
Re: Python3 work [was: The run up to Subversion 1.13.0]
Johan Corveleyn wrote on Wed, 18 Sep 2019 07:44 +00:00: > On Wed, Sep 18, 2019 at 9:31 AM Daniel Shahaf wrote: > > > > Johan Corveleyn wrote on Wed, 18 Sep 2019 00:48 +00:00: > > > No problem, after downloading py3c from Github, and adding > > > --with-py3c, I can start building it. > > > > What version of py3c did you download? HEAD or a release? > > Hm, I downloaded from master at https://github.com/encukou/py3c. Maybe > not such a good choice? > Should I go for 0.9 from https://github.com/encukou/py3c/releases instead? I didn't intend to imply that; I merely wanted to know which version to use for investigations and replication attempts. Note that on the /releases page there's a v1.0 dated three months after the v0.9, if you click "Show newer tags" at the top. I'm not sure why github doesn't offer that one. Cheers, Daniel
Re: Python3 work [was: The run up to Subversion 1.13.0]
On Wed, Sep 18, 2019 at 9:31 AM Daniel Shahaf wrote: > > Johan Corveleyn wrote on Wed, 18 Sep 2019 00:48 +00:00: > > No problem, after downloading py3c from Github, and adding > > --with-py3c, I can start building it. > > What version of py3c did you download? HEAD or a release? Hm, I downloaded from master at https://github.com/encukou/py3c. Maybe not such a good choice? Should I go for 0.9 from https://github.com/encukou/py3c/releases instead? -- Johan
Re: Python3 work [was: The run up to Subversion 1.13.0]
Johan Corveleyn wrote on Wed, 18 Sep 2019 00:48 +00:00: > No problem, after downloading py3c from Github, and adding > --with-py3c, I can start building it. What version of py3c did you download? HEAD or a release?
Re: Python3 work [was: The run up to Subversion 1.13.0]
On Wed, Sep 18, 2019 at 5:36 AM Branko Čibej wrote: > > On 18.09.2019 02:48, Johan Corveleyn wrote: > > On Mon, Sep 2, 2019 at 11:45 AM Julian Foad wrote: > >>> Troy Curtis Jr wrote: > James McCoy wrote: > > Finishing(?) and merging the Python3 support would be ideal. That would > > give one release for broader feedback before being in an LTS release. > It needs to get reintegrated with trunk again with the latest changes, > but the linux side of the house was looking good. It was in trying to > get my Windows Dev environment back up and running again that got me > frustrated and gave me an excuse to wander off doing other things... > IIRC, there is a build issue with the Py2 bindings in that branch on > Windows, but I never got far enough to check it out. > If there was someone who could help out on the Windows side, I can jump > in and get the branch up to trunk and retested in order to get this > thing over the finish line. > >> Johan Corveleyn wrote: > >>> I might be able to devote some time to this in the coming week(s), if > >>> you can tell me what I need to do / test / validate / ... :-). > >> Until Troy says something more specific, if you could switch to the > >> branch, catch-up merge from trunk, and see how much works on Py3 and on > >> Py2, that would be helpful. > > I'm sorry I missed the 1.13.x-branch deadline, but I finally got > > around to playing with the swig-py3 branch on Windows. > > Downloaded the latest Python release: 3.7.4. And using swig 3.0.12. > > > > Of course I didn't reread INSTALL, so I first ran into: > > > > [[[ > > WARNING: "C:\research\svn\dev\swig-py3\py3c\include\py3c.h" not found > > Use "--with-py3c" to configure py3c location. > > ]]] > > > > No problem, after downloading py3c from Github, and adding > > --with-py3c, I can start building it. > > > > However, I ran into the following error: > > > > [[[ > > c:\python37\include\pytime.h(123): error C4115: 'timeval': named type > > definition in parentheses > > [C:\research\svn\dev\swig-py3\build\win32\vcnet-vcproj\libsvn_swig_py.vcxproj] > > ]]] > > That makes no sense, my copy of pytime.h on Windows for Python 3.7.4 has > this on line 123: > > PyAPI_FUNC(int) _PyTime_FromTimeval(_PyTime_t *tp, struct timeval *tv); > > > Looks like perfectly valid C to me. So we'll need a bit more context to > see where the actual error is coming from. Not at my pc right now (I'll check again tonight), but from memory: I think my copy of pytime.h looks the same. Line 123 seems to be the first usage of 'timeval' though ... Is it possible that some include is missing, so there is no declaration of the timeval struct type? -- Johan
