Avoid duplication of effort #1
Conversation
[5.3][For real] The Catalina Merge
Fix typo and logic error in the overflow check in integerMultiply(), which was screwing up Decimal calculations under certain conditions. (cherry picked from commit 81fddf2)
[5.3] SR-13015: Decimal calculation incorrect on Linux
There are some issues in current implementation. To keep things simple, I'd like to extend test coverage of problem area first. Not all of new tests are expected to fail, but I find them useful to have. Co-authored-by: Andrew Druk <[email protected]> Co-authored-by: Anton Pogonets <[email protected]> (cherry picked from commit d6cb1ee)
This fixes typos in code responsible for counting operations in queue. (cherry picked from commit d8c2cfa)
- prevent releasing of stored value in `Operation._queue` property getter - balance retain count after current queue removed from thread-specific storage - make test_OperationWaitUntilFinished stable - extend test_OperationCount (cherry picked from commit 6257faa)
…f a directory was created by another thread concurrently. If another thread creates one of the same directories in the target path, the `!fileExists` check may pass while the `mkdir` call fails with `EEXIST`. However, if the existing file is a directory, then that should still be a success. Fixes [SR-12272](https://bugs.swift.org/browse/SR-12272). (cherry picked from commit b6eea02)
[5.3] OperationQueue fixes
[5.3] Return success from `FileManager` recursive directory creation even if a directory was created by another thread concurrently.
- fixes SR-13037 (https://bugs.swift.org/browse/SR-13037) (cherry picked from commit 0097ef2)
[5.3] fix convenience accessors on CocoaError and URLError
[5.3] improve URLError returned upon task cancellation
The static libraries need to link against additional dependencies, which are listed in the newly added modulemaps
Remove the absolute path to the host toolchain's stdlib from the three Foundation shared libraries.
Maybe they need to be compiled together.
|
@trunkmaster What do you think? |
|
@ethanc8 hi, probably I've missed your 2-week-ago PR, sorry.
It's excellent idea to merge our efforts! I've created this repo to avoid keeping patches inside NEXTSPACE.
My repo is based on the 5.9.2 branch of original Swift's version. I've noticed that CoreFoundation in Swift's repository changes not that often. I think your bridging to GNUstep-base would be a killer feature!
The main idea behind this fork is to create CoreFoundation to write C-based programms with all the power of CoreFoundation. For example, it helped me to rewrote large part of WindowMaker and get rid of WINGs and data management part of it (preferences, arrays, dictionaries etc.). The next major part is CFRunLoop and CFFileDescriptor implementation. I've managed to get X11 messages by monitoring CFFileDescriptor of X server connection inside CFRunLoop. Next big deal is a CFNotificationCenter implementation: I use it inside WM to pass messages inside C code and create a NSNotificationCenter<->CFNotificationCenter bridge. This part is usefull for notifications exchange between Obj-C and C programms. For example, GNUstep applications may send notifications to global notifications center and be catched by window manager (CFRunLoop, CFNotificationCenter) and vice versa. So to sum up, i've made the following changes:
You could track all my changes starting from 03eea75 commit. If you want I can configure this repo available for issues and PR. Also I want to keep this repo as CMake-based project. Do you want to become a contributor or will add your changes as PRs? |
|
@ethanc8 I don't quite understand what's going on here. I see CoreFoundation subdirectory with a bunch of C files (.c) renamed into ObjC files (.m). What do you include Swift code? How it should correspond to existing CF sources that already exists in my CF source tree? Could you please explain your idea of implementing CoreFoundation to GNUstep Base bridge? What mechanics of bridging you assume to implement? How ObjC classes should gain access to CF types and vice versa? |
|
@trunkmaster Please see https://github.com/ethanc8/CoreFoundation/blob/gnustep-bridging/CoreFoundation/Documentation/Bridging.md and https://github.com/ethanc8/CoreFoundation/blob/gnustep-bridging/CoreFoundation/TODO.md. I will try to write a better explanation of my changes this week. |
|
(this is a simplification, you need to read my commits in order to know everything I did, as I forgot many things that I did two years ago)
|
OK, my version of CoreFoundation is newer - 5.9.3.
What for? Is there any reason to make C library to look like ObjC?
I see no reason to build Apple library with GNUstep Make - my version builds before GNUstep Make even installed. Do you?
Great.That's the most interesting part for me. Could you please extract those 2 block of changes and prepare it to apply to my source tree? See my first post in this discussion.
Thanks, I'll try to understand idea. |
The point is not to look like ObjC; the point is to allow CoreFoundation to send Objective-C messages without having to manually call
I know how to use GNUstep Make, and don't know how to use CMake. GNUstep Make is also good at dealing with GNUstep libraries. That's pretty much the only reason why.
Sorry, I don't want to work on this. I want to focus on getting the tests to pass; if you need a CoreFoundation with bridging, just use mine. If I do want to rebase on a newer CoreFoundation, I will rebase on Ventura CoreFoundation, not Monterey CoreFoundation. |
I don't actually intend for this pull request to be merged (I wanted to file an issue but this repo doesn't accept issues), but we should avoid duplication of effort in our CoreFoundation ports. My CoreFoundation port is based off of swift-corelibs-foundation from Catalina (at some version of Swift 5.3, I don't remember which and I'm not very good at Git), and it supports bridging with GNUstep-base. In my
gnustepbranch, I just have a plain port of CoreFoundation to be buildable with GNUstep Make. Could you please explain what changes you've made in your fork more broadly and whether it would be better to build off of my fork or to start a new fork from a newer version of CoreFoundation?