[ Changing subject to get this unburried from a long semi-related
thread. More below. ]
On Tue, Dec 22, 2020 at 6:27 PM Yasuhito FUTATSUKI
wrote:
>
> On 2020/12/21 15:50, Daniel Shahaf wrote:
> > Johan Corveleyn wrote on Sun, 20 Dec 2020 23:05 +0100:
> >> On Sat, May 23, 2020 at 2:17 PM Yasuhito
On 2020/12/21 15:50, Daniel Shahaf wrote:
> Johan Corveleyn wrote on Sun, 20 Dec 2020 23:05 +0100:
>> On Sat, May 23, 2020 at 2:17 PM Yasuhito FUTATSUKI
>> wrote:
>>>
>>> On 2020/05/23 12:16, Daniel Shahaf wrote:
Yasuhito FUTATSUKI wrote on Sat, 23 May 2020 11:08 +0900:
> I think it
Johan Corveleyn wrote on Sun, 20 Dec 2020 23:05 +0100:
> On Sat, May 23, 2020 at 2:17 PM Yasuhito FUTATSUKI
> wrote:
> >
> > On 2020/05/23 12:16, Daniel Shahaf wrote:
> > > Yasuhito FUTATSUKI wrote on Sat, 23 May 2020 11:08 +0900:
> > >> I think it can be fixed by overriding _global_py_pool t
On Sat, May 23, 2020 at 2:17 PM Yasuhito FUTATSUKI wrote:
>
> On 2020/05/23 12:16, Daniel Shahaf wrote:
> > Yasuhito FUTATSUKI wrote on Sat, 23 May 2020 11:08 +0900:
> >> I think it can be fixed by overriding _global_py_pool to $input in "in"
> >> typemap, when $1 is updated. It assumes that there
On 2020/05/23 12:16, Daniel Shahaf wrote:
> Yasuhito FUTATSUKI wrote on Sat, 23 May 2020 11:08 +0900:
>> I think it can be fixed by overriding _global_py_pool to $input in "in"
>> typemap, when $1 is updated. It assumes that there are no APIs that
>> uses two or more result_pool like apr_pool_t * a
Yasuhito FUTATSUKI wrote on Sat, 23 May 2020 11:08 +0900:
> I think it can be fixed by overriding _global_py_pool to $input in "in"
> typemap, when $1 is updated. It assumes that there are no APIs that
> uses two or more result_pool like apr_pool_t * argument for allocationg
> return value.
What a
On 2020/05/22 8:02, Yasuhito FUTATSUKI wrote:
> On 2020/05/20 21:54, Jun Omae wrote:
>> On Mon, May 18, 2020 at 8:25 AM Yasuhito FUTATSUKI
>> wrote:
>>> Jun and I found it is caused by long existing bug on SWIG Python bindings,
>>> since before swig-py3 branch was merged (thus this bug exists on
On 2020/05/20 21:54, Jun Omae wrote:
> On Mon, May 18, 2020 at 8:25 AM Yasuhito FUTATSUKI
> wrote:
>>
>> On 2020/05/18 2:51, Johan Corveleyn wrote:
>>> On Sun, May 17, 2020 at 3:43 PM Jun Omae wrote:
>>
Assertion for negative ref count is raised from test_conflict
(client.SubversionCli
On Mon, May 18, 2020 at 8:25 AM Yasuhito FUTATSUKI wrote:
>
> On 2020/05/18 2:51, Johan Corveleyn wrote:
> > On Sun, May 17, 2020 at 3:43 PM Jun Omae wrote:
>
> >> Assertion for negative ref count is raised from test_conflict
> >> (client.SubversionClientTestCase).
> >> 1.10.x through trunk have
On 2020/05/18 2:51, Johan Corveleyn wrote:
> On Sun, May 17, 2020 at 3:43 PM Jun Omae wrote:
>> Assertion for negative ref count is raised from test_conflict
>> (client.SubversionClientTestCase).
>> 1.10.x through trunk have the issue.
> Thank you for the thorough research!
> I'm not sure what
On Sun, May 17, 2020 at 3:43 PM Jun Omae wrote:
>
> On Sat, May 16, 2020 at 9:13 PM Johan Corveleyn wrote:
> > If I apply your patch, I get this assertion with Python 3.8.2 and SWIG
> > 3.0.12:
> >
> > [[[
> > C:\research\svn\dev\trunk>python win-tests.py --log-level=DEBUG
> > --debug --swig=pyt
On Sat, May 16, 2020 at 9:13 PM Johan Corveleyn wrote:
> If I apply your patch, I get this assertion with Python 3.8.2 and SWIG 3.0.12:
>
> [[[
> C:\research\svn\dev\trunk>python win-tests.py --log-level=DEBUG
> --debug --swig=python R:\test_py
> Testing Debug configuration on local repository.
>
On Fri, May 15, 2020 at 11:27 AM Jun Omae wrote:
>
> On Wed, May 13, 2020 at 5:56 PM Jun Omae wrote:
> > At least, I think we should use python_d.exe when debug configuration.
> > ...
> > Python bindings with debug configuration for Python 3.x has something wrong.
> >
> > [[[
> > -- Running Swig
On Wed, May 13, 2020 at 5:56 PM Jun Omae wrote:
At least, I think we should use python_d.exe when debug configuration.
...
Python bindings with debug configuration for Python 3.x has something wrong.
[[[
-- Running Swig Python tests --
Traceback (most recent call last):
File "C:\usr\src\subv
On 2020/05/14 3:46, Johan Corveleyn wrote:
> On Tue, May 12, 2020 at 12:17 PM Johan Corveleyn wrote:
> ...
>> I'll try again later with Release mode. But just wanted to let you
>> know that the problem was not with building, but rather at runtime.
>
> Okay, tried again with Release mode, and then
On Tue, May 12, 2020 at 12:17 PM Johan Corveleyn wrote:
...
> I'll try again later with Release mode. But just wanted to let you
> know that the problem was not with building, but rather at runtime.
Okay, tried again with Release mode, and then it works :-). Great!
--
Johan
On 2020/05/12 19:17, Johan Corveleyn wrote:
On Tue, May 12, 2020 at 4:33 AM Johan Corveleyn wrote:
[[[
C:\research\svn\dev\trunk>python win-tests.py --log-level=DEBUG
--debug --swig=python R:\test_swigpython
Testing Debug configuration on local repository.
-- Running Swig Python tests --
Fatal
On Tue, May 12, 2020 at 7:47 AM Jun Omae wrote:
>
> Hi,
>
> On Tue, May 12, 2020 at 4:33 AM Johan Corveleyn wrote:
> > [[[
> > C:\research\svn\dev\trunk>python win-tests.py --log-level=DEBUG
> > --debug --swig=python R:\test_swigpython
> > Testing Debug configuration on local repository.
> > -- R
Hi,
On Tue, May 12, 2020 at 4:33 AM Johan Corveleyn wrote:
> [[[
> C:\research\svn\dev\trunk>python win-tests.py --log-level=DEBUG
> --debug --swig=python R:\test_swigpython
> Testing Debug configuration on local repository.
> -- Running Swig Python tests --
> Fatal Python error: _PyInterpreterSt
On Mon, May 11, 2020 at 7:08 PM Jun Omae wrote:
> See attached patch py38-windows-add-dll-directory--v2.diff.
I think I also ran into that error when I was testing 1.14.0-rc2,
while testing the swig-python bindings on Windows. But I had already
had so many problems that I gave up, and just signe
Jun Omae wrote on Tue, 12 May 2020 02:08 +0900:
> See attached patch py38-windows-add-dll-directory--v2.diff.
Thanks. The changes looks good to me. I don't have any further
comments, either. However, I'm not familiar with SWIG enough to be
comfortable +1'ing this for commit, so I'll let the oth
Thanks for the reviewing.
On 2020/05/11 0:57, Daniel Shahaf wrote:
Jun Omae wrote on Sun, 10 May 2020 13:27 +0900:
+def _dll_paths():
+import os
+if hasattr(os, 'add_dll_directory'): # Python 3.8+ on Windows
+cookies = []
+for path in os.environ.get('PATH', '').split(';
Jun Omae wrote on Sun, 10 May 2020 13:27 +0900:
> +++ subversion/bindings/swig/include/svn_global.swg (working copy)
> @@ -242,3 +242,40 @@
> +#ifdef SWIGPYTHON
> +/* Since Python 3.8+ on Windows, DLL dependencies when loading *.pyd file
> + * searches only the system paths, the directory contain
On Sun, May 10, 2020 at 1:27 PM Jun Omae wrote:
> I created patch to resolve the issue using moduleimport option of %module
> directive.
> After attached patch, *.pyd file is successfully loaded and tests for Python
> bindings pass.
Tested with the following environments:
- (Python 3.8.2, 3.7
Hi,
I noticed Python bindings is unable to load with Python 3.8.x on Windows, while
trying
to run check-swig-py.
[[[
C:\usr\src\subversion\trunk-py3> python.exe -c "from svn import core;
print(core.SVN_VERSION)"
Traceback (most recent call last):
File "C:\usr\src\subversion\trunk-py3\Release
25 matches
Mail list logo
