-
Notifications
You must be signed in to change notification settings - Fork 751
[WIP] handling ByRef arguments for method overloading - update methodbinder.cs #227
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
byref handling
TODO: take care of out parameters also |
grab the wheels from this place (navigate to specific python version and then artifacts tab): https://ci.appveyor.com/project/denfromufa/pythonnet/build/1.0.78 |
will there be a maintenance release soon ? |
@stonebig I just asked @tonyroberts what are the plans with pull requests and have not received any reply yet. in the meantime I mirrored pythonnet on bitbucket in case I have to fix the CI and merge pull requests faster: |
Any plans for any tests for this PR? The title is still WIP but am I to take it that it no longer is from your comments? |
@denfromufa Expecting a reply immediately from someone in a different time zone is unreasonable. If you want PRs to be merged in a timely fashion please ensure they include any relevant tests and are clearly explained. Labeling one as work in progress and then using it for a long discussion thread involving TODOs doesn't make it easy to determine when the right time to merge it is. @stonebig happy to do a maintenance release once these fixes are in. Looks like there are some problems currently on the mono side though, so those might have to be addressed first. |
My comments were in general for all PRs. There were some requests before I'm going to add tests to this pull request. On Thursday, June 23, 2016, Tony Roberts [email protected] wrote:
|
@denfromufa in order to close the PRs this morning I had to go through cherry-picking various commits out of them, amending changes because of improper formatting, and subsequently fixing bugs introduced due to a lack proper care and attention when submitting the PRs. Most of these had comments on them indicating that there were problems with them. In other open source projects, they would simply have been rejected but I took the time to fix them up and get them into the project. In the future, if you want PRs to be merged more quickly you may take it upon yourself to clean them up (code formatting, merge-commits that shouldn't be there etc.). If the merge is trivial and there is a decent explanation of what it is, and the code looks clean (and tested) I have no issue merging them immediately. If I have to spend time going through them and fixing them up then they will sit there until either they get closed or I have time to do it myself. |
@tonyroberts thanks for doing this tedious work with cherry-picking! Does this preserve the authors in the commits, i.e. will the authors of these original commits be listed in contributors to pythonnet? |
Yes
|
@denfromufa Is this one still relevant? |
byref handling:
#226