Hello Max,
i can´t agree with your thoughts regarding Swift. My point of view is there is no need to integrate a static typed language into GNUstep. Swift (as a bad copy of Kotlin) is only the (unfortunately successful) attempt of Apple to rob the Open Source community, pack it into Closed Software und avoid to give back any new ideas if there where any. Since Swift the power of innovation of Apple is round about 0, OK I forgot the phenomenal change to the opposite scrolling direction in macos invented by Federighi and the animated emogies.
As far as I understand GNUstep is the try to keep the idea of an open cross platform environment with a dynamic typed Language. The team is very small and my respect ist very big about the done work.
I read these discussions for a while as an interested mac user who don´t want to go back in prison with the M1 as it was in the PPC time and I am thinking about how I could help. Maybe the idea of connecting the apps together via (flexible) scripting could be a part of a careful thinking as every OS including macos lacks of really easy scripting ability for the end user. You know nearly every OPEN Source app (Gimp, Incsape, LibreOffice, Krita etc.) has this problem due to the different languages in they are written (Qt, GTK and so on) and don´t fit to Applescript. Photoshop would be history if more of the developers would realize a workflow doesn´t have to end inside the program. Could it be an advantage to offer this ability with GNUstep (steptalk) and integrate this as standard maybe a clickable choice for every programming project at start?
Sometimes I watch the "WWDC 1997: Steve Jobs about Apple's future“ at youtube and have to agree with Jobs about his view on focussing, Newton and what to do. Is now the time to open an additional source for problems with this sh..t a Swift or to strengthen the advantages of Objective-C? I think the attempt of Graham and Steven to improve simpleAgenda to reduce the pain of changing the OS for mac Users is one of the right ways.
Best regards
Thomas
I wonder if this is the correct understanding, using how things happened with Apple as a parallel:
* The old libobjc would be similar to Apple’s ARC-lite shipped in Mac OS X 10.6.8 or iOS 4.3. It will support some new features (eg syntactic sugars) but will have limitations on maintenance etc. * The new libobjc2 is required for all new language features Apple have added (eg Blocks) since then, with a big one IMO being any hope of integrating with the open source release of Swift language.
One thing we may need to do, is somehow make both libobjc use the same ABI.
p.s. GNUstep’s separation of gnustep-gui (AppKit) and gnustep-back can make reimplementing UIKit and SwiftUI that much easier. The latter will likely be a written in Swift but make heavy use of Swift-ObjC inter-compatibility to call into gnustep-back. Sent from my iPad Hi Po Lu,
On 2022-02-11 02:53:07 +0000 Po Lu <luangruo@yahoo.com> wrote:
> Before dropping GCC support in GNUstep, could you please consult with
> the developers of other GNU software which uses GNUstep?
>
> I put quite some effort into getting the GNUstep port of Emacs into a
> presentable state, which I would not have done had it not supported
> GCC.
>
> There are also many machines that aren't supported by LLVM, which a
> Clang-only GNUstep would not be able to run on.
Thank you for your supporting words.
I, too, appreciate the input. I am aware that LLVM/Clang doesn't work on many platforms. If you read the roadmap, you will see that the issues with both paths have their difficulties. > It would be best for someone to work on it, but if nobody does, I
> think
> GNUstep still needs to support GCC, at least for the important
> libraries
> such as gnustep-gui and gnustep-base.
and gnustep-back too :) of course
You seem to be under the false impression that there is a hard dependency on GCC. From a very strict point of view, NO, it doesn't. The base, GUI, and back libraries build just fine with no dependence on GCC whatsoever.
That is a direction I want to discuss with other core members.
There was a quorum (as you were not in attendance) of core members there during the initial discussion. The reason we are having another meeting is to clarify things. Maybe
it is possible with some clever use of macros and perahps defining a
perimeter in methods, or splitting classes and libraries. But a hard
migration for me is unacceptable.
A hard migration was not discussed and was not the intention. The idea was to draw up a roadmap that shows both ways forward.
This would of course pose a limit: the use of libobjc2 features inside
this "core", e.g. thorugh an upgrade like the scripts David metnioned.
I don't think it would be right to use objc2 features directly inside the "core" libraries (base, GUI, back, etc). This would limit the ability to use other compilers. The correct course would be to enable the use of so-called (16 year old) "modern" (ancient, really) features of objc2. We can compile such things out, if they are not available in whatever compiler is being used.
As already discussed, numerous times, to sum up here very quick...
TL;DR... 1) enhance libobjc2 to work on other platforms. 2) enhance gcc, libobjc, et al. to support more "modern" (as mentioned above) features such as @ literals and, most notably, ARC.
The long pole, between the two of these choices, is debatable. Enhancing the GCC compiler is possible, but is a lot of work.
ALso it would be an additional burden buecause two setups should be
tested (but in a certain sense, this is already done, but it is not
diverging).
I think this "migration" was put into air without thinking too much,
but just by the desire of it.
This "migration" or the "desire for it" is 16 years overdue. Just my 2c here.
Riccardo
--
|