Movatterモバイル変換

[0]ホーム
URL:

Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

 Sign up
Appearance settings

Add python buffer api support#980

Closed
thesn10 wants to merge 4 commits intopythonnet:masterfrom
thesn10:pybuffer2
Closed

Add python buffer api support#980
thesn10 wants to merge 4 commits intopythonnet:masterfrom
thesn10:pybuffer2

Conversation

@thesn10
Copy link
Contributor

@thesn10thesn10 commentedOct 27, 2019•
edited
Loading

What does this implement/fix? Explain your changes.

Passing data like images from managed to python will be easyer than ever!
I implemented the python buffer api which makes copying big chunks of data directly into the python object buffer possible!

You can copy strings to python object:

PyObject array = scope.Eval("bytearray(3)");byte[] managedArr = new UTF8Encoding().GetBytes(new char[] { 'a', 'b', 'c' });PyBuffer buf = array.GetBuffer(out bool success, 0);if (success){    buf.WriteToBuffer(managedArr, 0, managedArr.Length);    buf.Release();}

Or copy images to python byte arrays:

byte[] imageArr = LoadImage();PyObject array = scope.Eval("bytearray(" + managedArr.Length + ")");PyBuffer buf = array.GetBuffer(out bool success, 0);if (success){    buf.WriteToBuffer(managedArr, 0, managedArr.Length);    buf.Release();}

Does this close any currently open issues?

No

Any other comments?

...

Checklist

Check all those that are applicable and complete.

  • Make sure to include one or more tests for your change
  • If an enhancement PR, please create docs and at best an example
  • Add yourself toAUTHORS
  • Updated theCHANGELOG

Copy link
Member

@filmorfilmor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Thank you very much, this is a nice addition!

I've added a few general comments and will look into the Python-API details of this tomorrow.

@filmor
Copy link
Member

By the way, the failing CI is probably since you didn't addPyBuffer.cs to the old project files.

@thesn10
Copy link
ContributorAuthor

Fixed most of your comments. But i dont know why git marked almost all lines of the old csproject file as changed, even though i only added on line. I hope this is no problem :)

@filmor
Copy link
Member

You probably changed the line endings

@codecov-io
Copy link

codecov-io commentedOct 28, 2019•
edited
Loading

Codecov Report

Merging#980 intomaster willnot change coverage.
The diff coverage isn/a.

Impacted file tree graph

@@           Coverage Diff           @@##           master     #980   +/-   ##=======================================  Coverage   86.71%   86.71%           =======================================  Files           1        1             Lines         301      301           =======================================  Hits          261      261             Misses         40       40
FlagCoverage Δ
#setup_linux65.44% <ø> (ø)⬆️
#setup_windows71.42% <ø> (ø)⬆️

Continue to review full report at Codecov.

Legend -Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered byCodecov. Last update1463538...3edb8f5. Read thecomment docs.

Copy link
Member

@lostmsulostmsu left a comment•
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This PR needs unit tests with good coverage. Currently, basic functionality is non-functional.

_handle = _gchandle.AddrOfPinnedObject();
_view = (Runtime.Py_buffer)Marshal.PtrToStructure(_handle, typeof(Runtime.Py_buffer));

success = Runtime.PyObject_GetBuffer(obj, _handle, flags) >= 0;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Why return success/failure viaout, and not simply throw an exception?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

... in which case you also have to release resources.

lostmsu reacted with thumbs up emoji
Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Your right. My bad.

byte[] rawData = new byte[size];
_gchandle = GCHandle.Alloc(rawData, GCHandleType.Pinned);
_handle = _gchandle.AddrOfPinnedObject();
_view = (Runtime.Py_buffer)Marshal.PtrToStructure(_handle, typeof(Runtime.Py_buffer));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This is the only line where_view is initialized, however, at this moment the memory_handle points to is empty (e.g. all zeroes). So the_view is also always empty.
None of theifs below ever succeed.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Your wrong._viewshould be empty, because PyObject_GetBuffer fills_view with data. Everyif below works as expected

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@Sngmng you might be using some funky runtime, which makes this happen.PyObject_GetBuffer does not get a pointer to_view. It gets a pointer to therawData instead. The call toMarshal.PtrToStructure simply creates a copy of memory it is pointing to.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Oh my bad i messed up the order of these two lines when i was moving the code into the constructor. The PR was working before this commit tho.

}
}

public PyObject Object => new PyObject(_view.obj);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

CreatingPyObject does not increment reference counter of the object. You have to manually do it in this getter.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

But PyObject_GetBuffer() does. And PyBuffer_Release decrements the reference count... Just read the docs first.https://docs.python.org/3/c-api/buffer.html

Copy link
Member

@lostmsulostmsuOct 29, 2019•
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

But in this case you actually get a new reference, so you have to increase the recount, or cache the instance of pyobject in constructor.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Why am i getting a new refference? Isnt PyObject() just wrapping the handle that was already increfed? Whatever, im just going to add a XIncref as you say.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@Sngmng you are right, that it usually takes a pre-increfed pointer. But each instance requires its own incref. Otherwise when the instance is disposed, all other instances ofPyObject pointing to the same reference will simply crash on access.

public void Release()
{
Runtime.PyBuffer_Release(_handle);
_gchandle.Free();
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

It would be good to reset these handles to zero, and check, that the buffer has not been released yet.

public IntPtr buf;
public IntPtr obj; /* owned reference */
public long len;
public long itemsize; /* This is Py_ssize_t so it can be
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Py_size_t is not the same asInt64 akalong. There is an ongoing discussion about sizes of Python types.

Copy link
ContributorAuthor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Well it works withlong and i didnt see a reason to usePy_ssize_t if it will get casted to long anyway. I looked it up in the python source and it litteralytypdefsPy_ssize_t as long. What do you recommend to do?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

I don't know yet, as we did not work it out. C'slong is not the same as C#'slong. The later is alwaysInt64.

This code won't work on 32 bit systems. There C'slong is almost always ==Int32

Copy link
ContributorAuthor

@thesn10thesn10Oct 29, 2019•
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@lostmsu What about something like this:

[StructLayout(LayoutKind.Sequential)]internal struct Py_ssize_t{    [MarshalAs(UnmanagedType.SysInt)]    private IntPtr size;    public long GetValue()    {        if (Is32Bit)            return size.ToInt32();        else            return size.ToInt64();    }}

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@Sngmng this struct might not work either, because on 64-bit windowsIntPtr is 64-bit, butPy_ssize_t is probably 32-bit.https://stackoverflow.com/questions/384502/what-is-the-bit-size-of-long-on-64-bit-windows

And that problem will have to be solved, before PR is accepted.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

long and thus Py_ssize_t is 4 bytes on Windows (32 and 64 bit) and 8 bytes on other 64 bit systems. Very annoying.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

See my comment below, I made this mistake (assumingPy_ssize_t == long) before ;)

Py_ssize_t is a typedef forintptr_t orssize_t (on POSIX), so in all relevant cases it is equivalent in size toIntPtr.

@thesn10
Copy link
ContributorAuthor

thesn10 commentedOct 29, 2019•
edited
Loading

This PR needs unit tests with good coverage. Currently, basic functionality is non-functional.

Yeah it needs unit tests. But why are you claiming its non functional? Did you even test this PR? It works as expected. Just try out one of the examples i provided, you will see.

Apart from that, im going to implement all of your other requested changes like implementingIDisposable later this day

@thesn10
Copy link
ContributorAuthor

Ive implemented most of the requested changes, but i dont know what you want me to do with thePy_ssize_t fields? Leave them aslongs? Or use a struct like i proposed?

@lostmsu
Copy link
Member

lostmsu commentedOct 29, 2019•
edited
Loading

@Sngmng unfortunately, the only way I can think of so far is to have two struct types defined, and decide which one to use at runtime.

It is a sad state of things, I know.

@lostmsu
Copy link
Member

BTW, there appears to be a number of warnings regarding XML doc comments on the new file in the build, I guess related to the recent refactoring:https://ci.appveyor.com/project/pythonnet/pythonnet/builds/28472200/job/3otegb2hqnq9f6on

if (disposedValue)
throw new ObjectDisposedException("PyBuffer");
if (ReadOnly)
throw new Exception("Buffer is read-only");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

InvalidOperationException?

@filmor
Copy link
Member

Sorry for the confusion, we had this discussion already before (in#531) and the conclusion is thatPy_ssize_t is indeedIntPtr (notlong, though!), so if you change thelongs in thePy_buffer definition and ensure that the copy is done correctly this is fine. (Currently you do the copy toStrides etc. assuming you have 64bit data).

@lostmsu
Copy link
Member

lostmsu commentedOct 30, 2019•
edited
Loading

@filmor it might be fine for passing function parameters which will occupy an entire register anyway, but for structs incorrect size will cause the following fields to be incorrectly placed, leading to wrong memory being accessed.

If our tests are run on Windows x64 (which we should do exactly for this kind of issue) they will likely catch the problem.

@filmor
Copy link
Member

Hmm, it still seems to not quite work on x86, I'll try to reproduce this locally.

@lostmsu
Copy link
Member

@filmor weird, should not be a problem on x86.

@filmor
Copy link
Member

@filmor it might be fine for passing function parameters which will occupy an entire register anyway, but for structs incorrect size will cause the following fields to be incorrectly placed, leading to wrong memory being accessed.

If our tests are run on Windows x64 (which we should do exactly for this kind of issue) they will likely catch the problem.

I'm not sure what exactly this one was the answer to, butIntPtris the correct type (on both 32 and 64 bit systems) and should lead to the correct layout.

Interestingly enough, non-xplat built Py3.7 ran through on x86...

lostmsu reacted with thumbs up emoji

@lostmsu
Copy link
Member

@filmor you are correct.@Sngmng needs to investigate why non-xplat x86 builds fail.

@thesn10
Copy link
ContributorAuthor

Well, i tested Python 3.6 x86 + non-xplat. No errors at all.
Screenshot_111

Since i cant spot any error in the failing appveyor logs at all and my own test allways succeeds, Im beyond my capabilities. Maybe there is some config differences in the appveryor builds that cause the error? Maybe it randomly detects unmanaged memory copys and fails? I dont know man...

@filmor
Copy link
Member

Yeah, it doesn't really fail but times out. I'll try to reproduce it locally (running exactly what AppVeyor is supposed to run), but I don't use Windows as my primary dev platform, so I need a while to set everything up.

@filmor
Copy link
Member

@lostmsu Could you rereview already?

public static long SizeFromFormat(string format)
{
if (Runtime.pyversionnumber < 39)
throw new NotSupportedException("GetPointer requires at least Python 3.9");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Should the message say "SizeFromFormat ..." not "GetPointer ..."?

/// Copy contiguous len bytes from buf to view. fort can be 'C' or 'F' (for C-style or Fortran-style ordering). 0 is returned on success, -1 on error.
/// </summary>
/// <returns>0 is returned on success, -1 on error.</returns>
public int FromContiguous(IntPtr buf, long len, char fort)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Since this is a public method, why not throw aPythonException on failure?

throw new ObjectDisposedException(nameof(PyBuffer));
if (Runtime.pyversionnumber < 36)
throw new NotSupportedException("ToContiguous requires at least Python 3.6");
return Runtime.PyBuffer_ToContiguous(buf, _handle, _view.len, order);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Same, why not throw?

{
if (disposedValue)
throw new ObjectDisposedException(nameof(PyBuffer));
return Runtime.PyBuffer_FillInfo(_handle, exporter, buf, (IntPtr)len, _readonly, flags);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

And here

/// If this function is used as part of a getbufferproc, exporter MUST be set to the exporting object and flags must be passed unmodified.Otherwise, exporter MUST be NULL.
/// </remarks>
/// <returns>On success, set view->obj to a new reference to exporter and return 0. Otherwise, raise PyExc_BufferError, set view->obj to NULL and return -1;</returns>
public int FillInfo(IntPtr exporter, IntPtr buf, long len, int _readonly, int flags)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

_readonly should bebool

if (_view.ndim != 1)
throw new NotSupportedException("Multidimensional arrays, scalars and objects without a buffer are not supported.");

int copylen = count < (int)_view.len ? count : (int)_view.len;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This cast toint should bechecked to avoid data loss

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Also, I think it is wrong to silently write_view.len instead ofcount, whencount is> _view.len.
Return the number of bytes actually written, or throw an exception.

if (_view.ndim != 1)
throw new NotSupportedException("Multidimensional arrays, scalars and objects without a buffer are not supported.");

int copylen = count < (int)_view.len ? count : (int)_view.len;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This cast toint should bechecked to avoid data loss

@lostmsu
Copy link
Member

@Sngmng what's your solution architecture? VS has unexpected behavior when project and solution don't match. Also try running tests from command line like CI does it, e.g. withnunit3-console.exe

@thesn10
Copy link
ContributorAuthor

thesn10 commentedNov 1, 2019•
edited
Loading

@lostmsu I ran it throughnunit3-console and it timeouts at the exact same line as appveyor. Which is odd because the tests didnt even run...
The output is not very much and doesnt give any error.

PS D:\Users\user\Downloads\gitrepos\pythonnetsn\src\embed_tests\bin> nunit3-console Python.EmbeddingTest.dll --trace=VerboseNUnit Console Runner 3.10.0 (.NET 2.0)Copyright (c) 2019 Charlie Poole, Rob ProuseSamstag, 2. November 2019 00:00:32Runtime Environment   OS Version: Microsoft Windows NT 10.0.18362.0  CLR Version: 4.0.30319.42000Test Files    Python.EmbeddingTest.dll=> Python.EmbeddingTest.TestDomainReload.DomainReloadAndGC[Program.Main] === creating domain for assembly test1, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null[Program.Main] Before Domain Unload on test1, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null[Program.Main] After Domain Unload on test1, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null[Program.Main] The Proxy object is not valid anymore, domain unload complete.[Program.Main] === creating domain for assembly test2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null[Program.Main] Before Domain Unload on test2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null[Program.Main] After Domain Unload on test2, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null[Program.Main] The Proxy object is not valid anymore, domain unload complete.

@lostmsu
Copy link
Member

@Sngmng you can try--inprocess parameter, with and without debugger. E.g.https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-debug-from-a-dll-project?view=vs-2019

@thesn10
Copy link
ContributorAuthor

@Sngmng you can try--inprocess parameter, with and without debugger. E.g.https://docs.microsoft.com/en-us/visualstudio/debugger/how-to-debug-from-a-dll-project?view=vs-2019

If i try--inprocess:

NUnit.Engine.NUnitEngineException : Cannot run tests in process - a 32 bit process is required.--NUnitEngineExceptionCannot run tests in process - a 32 bit process is required.   bei NUnit.Engine.Runners.MasterTestRunner.InitializePackage()   bei NUnit.Engine.TestEngine.GetRunner(TestPackage package)   bei NUnit.ConsoleRunner.ConsoleRunner.RunTests(TestPackage package, TestFilter filter)

@lostmsu
Copy link
Member

@Sngmng build fails because of the wrong casing in Py_buffer.cs in csproj file

@lostmsu
Copy link
Member

@Sngmng you can tryhttps://stackoverflow.com/questions/1507268/force-x86-clr-on-an-any-cpu-net-assemblycorflags /32bit+ <PathToExe> to force nunit-console to run as 32 bit process (note, this is persisted).

If the binary is not AnyCPU, you could try building a x86 binary.

Copy link
Member

@lostmsulostmsu left a comment•
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

Looks good to me, as soon as tests pass in CI.
Maybe update CHANGELOG?

/// <summary>
/// Controls the <see cref="PyBuffer.Format"/> field. If set, this field MUST be filled in correctly. Otherwise, this field MUST be NULL.
/// </summary>
FORMATS = 0x0004,
Copy link
ContributorAuthor

@thesn10thesn10Nov 2, 2019•
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

This is originally namedFORMAT and notFORMATS but for some reason i get a "name not cls compilant" warning if i useFORMAT

@lostmsu
Copy link
Member

@Sngmng have you tried tests locally after removing finalizer? Do they pass?

@thesn10
Copy link
ContributorAuthor

thesn10 commentedNov 2, 2019•
edited
Loading

@Sngmng have you tried tests locally after removing finalizer? Do they pass?

Visual studio fooled me that they pass but they didnt when i retested throughnunit3-console. Weird.

@lostmsu
Copy link
Member

@Sngmng a sanity check: if you comment your tests out, do the tests pass?

@thesn10
Copy link
ContributorAuthor

thesn10 commentedNov 6, 2019•
edited
Loading

@lostmsu
Sometimes errors seem weird but the answer couldnt be more obvious.
So i was comparing my unit tests with the others and noticed that mine was the only one using aPyScope. And then it hit me: If i used aPyScope, did i callPy.GIL() first?! Well it turned out i didnt.
Im surprised it took me a week to notice this obvious cause.😑

lostmsu and thesn10 reacted with laugh emoji

@lostmsu
Copy link
Member

@Sngmng hahaha, now I remember facing the same issue. Damn. Looks like we should add GIL checks to many entry points...

@thesn10
Copy link
ContributorAuthor

thesn10 commentedNov 6, 2019•
edited
Loading

@lostmsu yeah would be better hahaha. But the tests seem to fail again... seems likePy.GIL wasnt the only cause.. 😭

@filmor
Copy link
Member

At least the failure is now less erratic in that it fails exactly for all Python 3 versions on Windows running on x86 :)

@amos402
Copy link
Member

They should not be running in parallel. The test failure looks like it happens because of python engine reinitialization.@amos402 can you take a look at this PR to see if anything here could have corrupted memory on domain reinitialization? I don't see anything, but maybe you'll notice some issue.

@Sngmng , try removing finalizer on the buffer class. If that helps, we may have to take in PR without it, and reintroduce it later.

I'm not sure about that, maybe the cause is callingPyBuffer_Release in~PyBuffer, it have not been got GIL before callingPyBuffer_Release(destructor called in GC thread). Also the destructor may call afterPy_Finalize.

btw. I wonder why thePyBuffer not making an implementation ofSystem.Stream?

filmor and lostmsu reacted with thumbs up emoji

@filmor
Copy link
Member

AStream implementation is (I think) out of scope here, but the GIL comment is valid.

@lostmsu
Copy link
Member

@Sngmng can you rebase/mergemaster and update thePyBuffer finalizer to behave similarly to the one inPyObject (see latest changes inmaster)?

@thesn10
Copy link
ContributorAuthor

@Sngmng can you rebase/mergemaster and update thePyBuffer finalizer to behave similarly to the one inPyObject (see latest changes inmaster)?

yeah sure

lostmsu reacted with thumbs up emoji

@dnfclas
Copy link

dnfclas commentedMay 14, 2020•
edited
Loading

CLA assistant check
All CLA requirements met.

@thesn10
Copy link
ContributorAuthor

Why is appveyor configured to do the conda build? I mean it fails everytime and is ignored anyway? And it takes 6min which is a lot. Removing these checks would improve the test speed to 1min which is a 6 times speed improvement. I am waiting multiple hours for appveyor because it is so slow, just because of the unnecessary conda build...

@lostmsu
Copy link
Member

Related:#1063

@lostmsu
Copy link
Member

@Sngmng the issue was just fixed in master by filmor.

@lostmsulostmsu added this to the3.0.0 milestoneMay 22, 2020
@lostmsu
Copy link
Member

Given 2.5 is just around the corner, and in 3.0 I'd like to fix#980 , which might affect the interfaces proposed here, I suggest we get it after 2.5 is released (should be soon).

@Sngmng the issues you mentioned are fixed inmaster, you should be able to update the finalizer now.

@thesn10
Copy link
ContributorAuthor

Be aware that the last commit to update the finalizer is still untested because i had some problems using nunit and couldnt run the tests.

@codecov-commenter
Copy link

codecov-commenter commentedMay 23, 2020•
edited
Loading

Codecov Report

❗ No coverage uploaded for pull request base (master@49a230b).Click here to learn what that means.
The diff coverage isn/a.

Impacted file tree graph

@@            Coverage Diff            @@##             master     #980   +/-   ##=========================================  Coverage          ?   86.66%           =========================================  Files             ?        1             Lines             ?      300             Branches          ?        0           =========================================  Hits              ?      260             Misses            ?       40             Partials          ?        0
FlagCoverage Δ
#setup_linux65.33% <ø> (?)
#setup_windows72.00% <ø> (?)
Impacted FilesCoverage Δ
setup.py86.66% <0.00%> (ø)

Continue to review full report at Codecov.

Legend -Click here to learn more
Δ = absolute <relative> (impact),ø = not affected,? = missing data
Powered byCodecov. Last update49a230b...530e8c7. Read thecomment docs.

@lostmsu
Copy link
Member

@Sngmng oh, yourDispose method was perfectly fine. It is the finalizer (e.g.~PyBuffer()), that needed to be updated.

@lostmsu
Copy link
Member

Somehow this is already in o-O

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

@filmorfilmorfilmor left review comments

@lostmsulostmsulostmsu approved these changes

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

3.0.0

Development

Successfully merging this pull request may close these issues.

7 participants

@thesn10@filmor@codecov-io@lostmsu@amos402@dnfclas@codecov-commenter
[8]ページ先頭
©2009-2026 Movatter.jp