Please don't attack each other. I'm pretty sure the GNUStep is a worthy project, and I also think that Chris might've misunderstood what level of support Lars meant Swift should give it.
But Gregory, you as well should chill and not attack Chris personally. They have made a mistake, but that doesn't mean you should talk like so.
Thanks for coming to this thread, though. It's important to have you here advocating for your project.
Your third point is also incorrect. GNUstep is almost on par with both KDE and GNOME. Some features are lacking, but most are there. Considering that GNOME has the backing of a foundation which receives millions of dollars in contributions and employs full time developers to improve the framework and that GNUstep has NONE of these advantages speaks to the dedication and determination of my team and it is shameful that GNUstep has not received the recognition and the attention that it has so richly deserved for many years. For me GNUstep is a labor of love. And I have been repeating myself for 15 years trying to convince people that GNUstep has followed cocoa and that we did not stop at openstep or nextstep!! Do we seem like idiots to most of you? How useful would it be if we did that?
GNUstep has been used in major applications such as at an aerospace company (xcor) and on millions of android devices thanks to Apportable using it as a major part of their implementation of UIKit. So, please, don’t fool yourselves or, worse, the rest of the community into believing the, common, false narrative. Does GNUstep have a ways to go, yes, are we dead. LIKE BSD.... hell no. I’m tired of saying so. Our last release was about 2 months ago.
Do yourself a favor... take a look at the actual code in the repo... because you apparently don’t know what you’re speaking about.
I’m not attacking him personally. I didn’t say anything to Chris other than I will fork his project. That is not an attack, it’s a promise. Regarding Swift’s adoption on the macOS desktop what I’m stating is fact, not an attack. I’m sorry if the truth offends. I am sure of this since I have been a macOS Developer since NeXT was bought and an OPENSTEP developer before that.
I am the person who about two years ago began an implementation of swift on my own for fear that apples version wouldn’t be open sourced. I have the necessary experience to implement these things if needed, but I would much rather work with you guys. I believe there is value in doing this as GNUstep is in need of more developers and this would bring some much needed attention to the project. It would also provide a way for many developers to port their applications (if they are indeed implemented in swift).
All I believe is needed is a way to allow the runtimes to communicate. This may be beyond my understanding at present and may, indeed, be why Chris is saying it’s too complex. I have no clue about Swift’s implementation.
This stands out, hence the quote, but your comments read like those of a petulant child. Perhaps it is cultural, but you seem rather combative, and such an attitude is not going to invite Swift developers to aid in interop with GNUstep.
My apologies but I’m tired of correcting the same misconceptions again and again over the last 15 years. I would very much like to have interoperability with swift.
Then it seems like the Swift community is lucky to have just the right person to make sure that can happen. Would be amazing to have someone with your skillset on board!
Okay, I think there are frayed nerves on several sides here. This is why I stepped in earlier to try to clarify that supporting ObjC on non-Darwin platforms was a reasonable and not overly-burdensome goal. Let's continue the conversation from there and stay away from statements that might be perceived as dismissive of other people's work.
I have never met you, and I'm sorry I apparently offended you. One random thing: I'd like to inform you that this is not "my" project. If we ever cross paths, I'd be happy to buy you a beer sometime to learn more about your project.
I'm sorry that I offended you. Just to be clear, I'm a contributor to the project and I don't speak for it. As a contributor, I was just trying to ascertain what scenarios are "actually supported", "theoretically supported", or simply just "unexplored".
If we ever cross paths, I too would be happy to buy you a beer too and learn more about where GNUstep is headed.
If someone wanted to make a Swift environment that interoperated with a runtime environment other than ObjC, like maybe GObject, COM, or Qt, that might be an interesting project too.
Same here. I sincerely apologize for how I came across.
Please understand it is rooted in a deep frustration stemming from misconceptions such as those put forward earlier in this thread.
If there is some way I can help support objective c interoperability then I am willing to do that.
Same here. I apologize for how I came across. I would very much like to work with you guys to determine what is possible. If it is, indeed, practical to do this with minimal impact to the main compiler code then I would very much like to help.
Swift's IRGen reimplements a lot of ObjC codegen, but we should really adopt Clang's existing interfaces for generating runtime metadata, which should hopefully get us a good way toward runtime-agnostic code generation on the compiler side. On the runtime side, a lot of the runtime interop logic for String/Array/Dictionary/Set interop is closely tied to Apple's implementations of these things in their Foundation, but the Foundation team is in the process of implementing the same functionality for interop with their swift-corelibs port on Linux. The high-level interfaces for bridging by now are hopefully decoupled enough that adding new bridging implementations for other Foundations is straightforward at this point; maybe @millenomi can speak to her experience getting bridging to work on Linux.
I would love to find a way to re-use Clang's interfaces for generating runtime metadata. Unfortunately, those interfaces are based pretty deeply on having
clang::ObjCInterfaceDecls, which is totally reasonable for Clang but inconvenient for Swift. It's probably not ridiculous to fake those up in Clang IRGen, although we would at a minimum need to be able to provide a custom IMPL for methods, as well as customizing things like e.g. setting custom flags on the RO-data pointer.
The bigger issue with bridging is
_SwiftValue; the current implementation, and the one that I'm about to land, are both tied to their respective Foundation implementations in some significant ways — one requires Apple's ObjC runtime, and the other makes assumptions to what SPI swift-corelibs-foundation implements. The other bridging bits are decoupled entirely.
I need to determine where the best place to start is at this point. I am just getting familiar with the swift codebase.
I'm not trying to provoke anybody by sharing this, but just want to point out that often when people speak of GNUStep, I learn that they are unaware of another project called Cocotron, which is similarly designed to support adapting Objective-C and Cocoa code to Windows and Linux:
I think that in surveying options for supporting ObjC runtimes on non-Darwin platforms, it probably makes sense to at least evaluate that codebase. I've never used either GNUStep or Cocotron substantially but one thing that has always appealed to me about Cocotron is its MIT license.
That project looks unmaintained now. So I would have doubts about linking with it.