Hi Stefan, Just applied the patch into the pull request in a way that the history looks okay. Could you have a look and see if it's mergeable?
Thanks, -- Daniel. On Wed, Aug 23, 2017 at 3:23 PM, Stefan Bidigaray <stefanb...@gmail.com> wrote: > Hi Daniel, patch is attached. I couldn't really figure out how to work the > format-patch thing, but did the next best thing. > > On Wed, Aug 23, 2017 at 10:30 AM, Daniel Ferreira (theiostream) > <bnm...@gmail.com> wrote: >> >> Hi Stefan, sorry for taking a day to answer; I was absent yesterday. >> >> Can you generate a patch for your changes with `git format-patch` and >> send them to me? I can embed them into my pull request and make them >> look nice with Git history. Afterwards, you could merge it. >> >> -- Daniel. >> >> On Tue, Aug 22, 2017 at 4:56 PM, Stefan Bidigaray <stefanb...@gmail.com> >> wrote: >> > I have what I believe is a solution to this PR, however, I do not >> > actually >> > know how to go about fixing the PR and pushing the changes. I was >> > successfully able to get Daniel's branch and made the modifications. Now >> > I'm >> > not sure how to commit and push the changes to the repo. Can anyone give >> > me >> > nudge in the right direction? >> > >> > On Tue, Aug 22, 2017 at 2:41 PM, Stefan Bidigaray <stefanb...@gmail.com> >> > wrote: >> >> >> >> So CFBridgingRelease() essentially calls -autorelease, and >> >> CFBridgingRetain() -retain? I kind of get why, but only after thinking >> >> about >> >> it for an hour. >> >> >> >> On Tue, Aug 22, 2017 at 12:56 PM, Fred Kiefer <fredkie...@gmx.de> >> >> wrote: >> >>> >> >>> >> >>> > Am 22.08.2017 um 17:15 schrieb Stefan Bidigaray >> >>> > <stefanb...@gmail.com>: >> >>> > >> >>> > Hi everyone, >> >>> > This message is mostly for Daniel, but anyone with some experience >> >>> > using these functions should not hesitate to add their thoughts. >> >>> > >> >>> > Daniel, I just noticed your pull request on github last night. I'm >> >>> > good >> >>> > with most of it, my only concern is the bridging functions. I made a >> >>> > comment >> >>> > last night, but later discovered I misunderstood their purpose. I'd >> >>> > like to >> >>> > get your pull request merged, and want do discuss it before we move >> >>> > forward. >> >>> > >> >>> > My understanding of the documentation for CFBridgingRelease and >> >>> > CFBridgingRetain is that they are essentially no-ops, unless ARC is >> >>> > in >> >>> > effect. And even when ARC is being used they do not do anything >> >>> > other than >> >>> > tell the compiler that the object is now controlled by ARC. With >> >>> > that in >> >>> > mind, these two "functions" should do nothing other than cast the CF >> >>> > object >> >>> > as an ARC aware object, and nothing at all if ARC is not >> >>> > implemented. Does >> >>> > this sound reasonable? Another part of this conversation is where do >> >>> > these >> >>> > functions belong. According to the Apple documentation, they are >> >>> > part of >> >>> > Foundation, so should they not be in Base, instead? >> >>> > >> >>> > As for CFAutorelease, I think this is the function where >> >>> > objc_autoreleaseReturnValue() needs to be used. The documentation >> >>> > for this >> >>> > function is nonexistent, so I'm just guessing at what it really >> >>> > does. >> >>> > >> >>> > Any thoughts? Anyone? >> >>> >> >>> >> >>> Stefan, >> >>> >> >>> I think you are mostly correct. Apple has this stuff in Foundation, >> >>> but >> >>> we don’t build base on top of CoreFoundation, so we need to have it >> >>> the >> >>> other way around. In ARC-mode these two functions should call the >> >>> compiler >> >>> primitives David pointed to. Where you are incorrect is the >> >>> non-ARC-mode. >> >>> There Apple seems to implement these functions as retain and >> >>> (auto-)release. >> >>> Don’t ask me why, your interpretations makes more sense to me. >> >>> >> >>> Fred >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> Gnustep-dev mailing list >> >>> Gnustep-dev@gnu.org >> >>> https://lists.gnu.org/mailman/listinfo/gnustep-dev >> >> >> >> >> > >> > >> > _______________________________________________ >> > Gnustep-dev mailing list >> > Gnustep-dev@gnu.org >> > https://lists.gnu.org/mailman/listinfo/gnustep-dev >> > > > _______________________________________________ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
