Re: Which ObjC2.0 features are missing in the latest GCC?

[Riccardo Mottola]

On 11/27/19 12:14 PM, Andreas Fink wrote:

What are you using to write your ObjC code?



I don't like my own answer: but it is Emacs with GTK backend! Or Emacs 
on MacOS! Ah!


I set-up the project with ProjectCenter and XCode, but then use Emacs.

And I do not like Emacs... but it is the only editor that reliably 
formats the Obj-C in GNU-style.



Not only I would love to use Vim which I prefer and use for all the rest 
(C, C++, Assembly, XML..) but it irks me that it is Emacs with GTK. I 
would so much be able to reliably use the GNUstep version of it :-P I 
regularly try, but fail to get something reliable.



But this is becoming really off-topic! :-P


Riccardo

Re: Which ObjC2.0 features are missing in the latest GCC?

[Riccardo Mottola]

Hi,


On 11/26/19 4:48 PM, Stefan Bidigaray wrote:


How about a compromise? How hard would it be for GCC to drop the GCC 
runtime in favor of GNUstep runtime, and implement everything except 
ARC and blocks (these seem to be the biggest road blocks)? While ARC 
and blocks are important for many developers, GNUstep itself is not 
directly dependent on the compiler supporting these features. Ideally, 
we could get to a situation where GCC and Clang compiled binaries can 
interoperate. Or am I way off?



for a while, I used the "new" runtime with GCC (and built with GCC of 
course) but somewhen it stopped to be possible. I tried some work with 
David, but eventually gave up.



Riccardo

Re: Which ObjC2.0 features are missing in the latest GCC?

[Riccardo Mottola]

Hi,

On 11/25/19 12:05 PM, H. Nikolaus Schaller wrote:


Please count me as manpower you loose by deprecating GCC (even if I 
contribute only indirectly through my project mySTEP). So this is not 
a simple reprioritization.



I know :-P I always hoped in more cross-breeding. But sometimes few 
contributions are of great value, compared to many small.. not easy to 
but them on a scale!



But you could probably loose me as manpower as well or, at least, 
greatly reduce my interest.


I don't claim my contributions are of any more value than yours, but 
they are direct to many GNUstep specific applications.



Riccardo

Re: Which ObjC2.0 features are missing in the latest GCC?

[Riccardo Mottola]

Hi,


On 11/24/19 2:25 PM, Fred Kiefer wrote:

This is an interesting plan, but one not shared by many GNUstep developers. For 
me it is fine if you set up a Foundation replacement that is based on Apples 
CoreFoundation code and I am even willing to help you to get GNUstep gui 
working with this setup, but I would never contribute myself to this 
development and don’t see it as part of GNUstep. You see, GNUstep as a 
community is a very broad concept. Some of us are willing to work on a desktop 
environment others are into obscure hardware support. But the base of GNUstep 
are the libraries that allow writing or porting ObjC applications in a 
completely free environment. The direction you are heading for is in my view 
outside of that scope.



I totally agree here.


There also developers who like to work with GUI apps on obscure 
platforms, don't forget :-P



Riccardo

Re: Which ObjC2.0 features are missing in the latest GCC?

[Riccardo Mottola]

Hi,


On 11/24/19 10:11 AM, Max Chan wrote:
I would like to add another plus for dropping GCC: if we want any hope 
for Swift interworking, we have to use clang as the compiler.


Apple have no plan to provide any GUI support on Linux version of 
Swift. If we have Swift interworking, even though we may have to drop 
our own libobjc, Foundation and CoreFoundation in favor of Apple’s 
release, the GNUStep GUI package can provide the replacement AppKit 
that Apple’s Swift release lacked.




I would add that as a minus and warning point.

Should we really follow Apple blindly in these decisions? I don't think 
so. Apple's interest in MacOS long dwindled and became apparent in its 
renaming as macOS.


I personally don't care about Swift... but I would find if useful for 
the FOSS world if people could use Swift + GNUstep.



But here a question: what if in the future Apple will switch over to 
Swift totally? An evolution in the APIs and hypothetical Swift 2.0 which 
would make Objective-C incompatible. What then? Should GNUstep follow 
blindly?


It is the same question we are having here now, just time-shifted. I 
suppose you can guess my answer implicitly.



Riccardo

Re: Which ObjC2.0 features are missing in the latest GCC?

[Riccardo Mottola]

Hi,


On 11/24/19 2:24 AM, Yavor Doganov wrote:

I don't know why Debian is important, but they cannot be made
available as an option.  It would mean duplicate packages with
different names -- the release team will not allow it and the
ftpmasters will not allow it.



I can tell for my experience why Debian is important: it has been my 
first serious Linux distribution after coming from NetBSD. It was the 
only distribution which support(ed) 68k!


Also, it is still important now because it is the base for Ubuntu, a 
very popular distribution which often carries on things from Debian "as 
is". Raspbian is also debian based. So, supporting Debian well, helps a 
big part of the FOSS community.


While I still use Debian on PowerPC, I now switched to Devuan on amd64 
and x86 for a reason you can imagine ad a very unfortunate Debian 
decision, but I still feel "at home" like on older Debian.




You probably weren't around when we (GNUstep people in Debian) had to
scrap and fight to prevent it from being removed.  GNUstep in Debian
back then was undermaintained and violated the FHS, it was also full
of bugs (that is, obvious bugs such as frequent failures to build from
source) and blatant bugs solely due to packaging.  Hubert wrote a tool
to FHS-ify most of the packages, we fixed most bugs and we had a
helping hand from the Debian GCC maintainers who said it would be very
worthwile to keep GNUstep in Debian, at least as a testing ground for
GCC.



Although I never liked that FHS imposition, I think too it was very 
worthwhile!


Also, it meant packagers and users: I got bug reports and patches which 
contributed in making upstream software better.





And that's what it's been, more or less; GNUstep had a rapid decline
in the user base some years ago and it appears it is not going to
recover.  All the Clangs in the world are not going to help you with
that.  But in your quest for popularity you may lose some of the solid
foundations that are still keeping this project afloat.



I agree on that, although I don't know how hoe accurate those statistics 
are (since popcon never worked for me in 10 years!). Most persons will 
install GNUstep on Debian for its applications and we know that it is 
not very appealing since a long time. Although "now" you could argue 
that there is no development due to lack of clang, it would be a 
fallacy: the reasons are much older and deeper than that!



Riccardo

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 29.11.2019 um 17:30 schrieb Riccardo Mottola :
> 
> Hi,
> 
> Derek Fawcus wrote:
>> While dropping support for GCC does not strike me as a problem,
>> switching the core implementation to depend upon C++ may well do.
>> 
>> How many developers are comfortable with C++?
> 
> I don't like it. Actually, my love for GNUstep is not only the OpenStep-like 
> API, but Objective-C (1.0) which is just a language I grew in very well

I have a very similar preference.

> I don't like C++, although it has some merits, it is easy to write complex 
> code. I do work on projects wich use C++ extensively and I hate districating 
> myself in the tangle of C++-isms.
> It is a matter of taste, I suppose.

This touches a quite fundamental aspect of programming languages: complexity of 
concepts, writeability, readability, and reliability (bug free) and maybe more.

These are in conflict and every language tries to optimize in one direction on 
the cost of something else.

I would for example say:

ObjC1:
- low concept complexity: there are just some @keywords for defining classes 
and methods, id type, [] to call methods and delegation to handle callbacks.
- This leads to "prosa" code which can be easily read even 10 years after 
writing.
- Writing takes more time and the programmer has to explicitly care about 
alloc/copy/retain+release.
- unless the programmer or reviewer knows the rules by heart there may be bugs 
by wrong memory management

C++:
- high concept complexity: overloading of operators, templates just to name some
- This leads to cryptic code and can make it very difficult to undertstand what 
is going on
- writing is less typing effort if someone knows the concepts

ObjC++ and ObjC-2 try to find a synthesis on different levels:

ObjC++ mixes both leading to code which has just some of the benefits but all 
drawbacks.

ObjC2 tries to add type safety, ARC, dot notation, blocks to make the 
programmer press less keys.
ARC and type safety can reduce the number of bugs.
But code can become more difficult to read and understand.

Swift: simplifies some things compared to ObjC2 (by removing C heritage) and 
adds new things like optionals.

So I personally prefer ObjC1 because of the high readability and low complexity 
of concepts and the additional effort of more typing [] instead of . and taking 
care of retain/release does not feel like a big burden. So that I can focus on 
the algorithms instead of finding tricky notation for what I want to express.

Others prefer (understandably) ObjC2 because it looks more familiar if they did 
learn JAVA before.

And still others prefer Swift because it is tagged as "modern".

> 
> Since GNUstep for me is in great part "fun" (although I managed to get some 
> enterprise tools done, they are still Open Source) coding for it should 
> retain (no pun on ARC intended) this fun part.

Yes, fun is a big part. It is just different what people consider as fun: Jazz, 
Pop, Heavy Metal, Folk songs, Operas etc...

BR,
Nikolaus

Re: Which ObjC2.0 features are missing in the latest GCC?

[Riccardo Mottola]

Hi,

Derek Fawcus wrote:

While dropping support for GCC does not strike me as a problem,
switching the core implementation to depend upon C++ may well do.

How many developers are comfortable with C++?


I don't like it. Actually, my love for GNUstep is not only the 
OpenStep-like API, but Objective-C (1.0) which is just a language I grew 
in very well


I don't like C++, although it has some merits, it is easy to write 
complex code. I do work on projects wich use C++ extensively and I hate 
districating myself in the tangle of C++-isms.

It is a matter of taste, I suppose.

Since GNUstep for me is in great part "fun" (although I managed to get 
some enterprise tools done, they are still Open Source) coding for it 
should retain (no pun on ARC intended) this fun part.


Riccardo

Re: Which ObjC2.0 features are missing in the latest GCC?

[Riccardo Mottola]

Hi Ivan,

Ivan Vučica wrote:
Now, I see what David says about use of C++ in implementation of 
Foundation... but I’d expect that putting C++ would bring the 
compilation times up for everyone. Not a showstopper, but there’s 
something cool about all of GNUstep being buildable really quickly 
(configure steps usually taking longer than the build of the project 
itself).



I sincerely would prefer not to pull C++ in. It is not just a matter of 
"speed" but also of trouble. As well as of sheer "installed size". The 
C++ part is the most troublesome and unportable. in GCC for example, 
using it on different platforms, it is most often easy to upgrade C and 
Obj-C to a newer version, but it is always C++ giving issues, both with 
headers as well as link time.


I am very proud that you can build ALL GNUstep parts I use except one 
single component without C++, it is very easy on certain installation 
and the choice I did on Raspberry, for example (even if there C++ 
works). The only component which needs C++ currently is PDFKit because 
of xpdf. Obj-C++ is not needed because of a wrapper.


Riccardo

Re: Which ObjC2.0 features are missing in the latest GCC?

[Riccardo Mottola]

Hi Fred,

Fred Kiefer wrote:

There are many benefits that ObjC 2.0 support with clang could bring, still I 
can understand why some people prefer to stay with a compiler and a language 
they know. I myself use gcc and even with its limitations it allows me to do 
useful programming for GNUstep. And many times gcc has pointed to bugs in the 
code where clang accepted the code. (The opposite is also true, it really has 
been good for us to have two different compilers to inspect our code.) What I 
would never do is to argue for others to use gcc. Just use the compiler you 
prefer.


this is exactly my thought too. I would go further: dependening on the 
system, one compiler is better than the other, one release is better 
than the other. Newer is not always better. E.g. very good releases of 
gcc are 4.8 and 6.5, clang 3.9 and 6.0 . Clang 4.0 was close to 
unusable... But then you have CPU... on PPC32 GCC is the only way to go.


It is really in the interest of "freedom", that is, free software, 
support more compilers! Sometimes you discover wonderful words, e.g. all 
the efforts of Fienix Linux and PPC linux.. the PPC project - 
requirements there are different.


The nice thing about GNUstep was exactly its freedom and versatility. No 
C++ requirements, Compiler freedom, even if that sometimes means 
complications. NetBSD, OpenBSD, FreeBSD, Solaris... and MinGW/MSYS (pain 
in the ass! here compiler versions are really really tricky)


*if* you want something mainstream, then you go MacOS or Windows 
directly! Or some standard Linux.


Riccardo

Re: Which ObjC2.0 features are missing in the latest GCC?

[Bertrand Dekoninck]

> Le 28 nov. 2019 à 17:47, Pirmin Braun  a écrit :
> 
> On Wed, 27 Nov 2019 12:14:39 +0100
> Andreas Fink  wrote:
> 
>> What are you using to write your ObjC code?
> 
> sublime text 3.3.2
> 
> but I miss the column view with the class hierarchy and the method names from 
> ProjectBuilder

Emacs, Gemas or Project Center, for the small amount of code I’ve written.
Bertrand

Re: Which ObjC2.0 features are missing in the latest GCC?

[Pirmin Braun]

On Wed, 27 Nov 2019 12:14:39 +0100
Andreas Fink  wrote:

> What are you using to write your ObjC code?

sublime text 3.3.2

but I miss the column view with the class hierarchy and the method names from 
ProjectBuilder

-- 
Pirmin Braun p...@pirmin-braun.de +49 261 92199400 +49 174 9747584 
Geschäftsführer der Pirmin Braun GmbH www.pirmin-braun.de 
Im Palmenstück 4 - 56072 Koblenz - www.facebook.com/PB.ERP.Software
Registergericht: Koblenz HRB 26312 UStID: DE319238613 Steuernummer: 22/656/03918

Re: Which ObjC2.0 features are missing in the latest GCC?

[Liam Proven]

On Wed, 27 Nov 2019 at 12:15, Andreas Fink  wrote:

>
> On the other hand I would _LOVE_ to see a OS X like desktop with AppKit and I 
> would spend time working on it. Given the other desktops under Linux have not 
> much success because of the way they do certain things, I think there is a 
> big need. Something like what ElementaryOS does but with GNUStep and running 
> on the major distributions (Debian/Ubuntu/Fedora/Redhat/Centos) could change 
> the world. This is a long shot. But we have to ask ourselfs what is our 
> strategy for the future.

Absolutely, this.

Given the goals of the ElementaryOS desktop and team, it is a crying
shame they didn't use GNUstep to build it. I am sure they would have
got to a rich, usable product much quicker. I suspect they just did
not know GNUstep existed.

That awareness is key, and it is why I think having at least one
mainstream distro having a full GNUstep desktop available is vitally
important. I know that the GNUstep developer community don't see what
they're doing as a desktop environment, but that is accidentally what
they have built, and that is the № 1 best way of getting visibility
and awareness.

> a) a EASY to use entry. Run on any version of Ubuntu, Debian, CentOS, Redhat 
> etc with just a simple setup.  ./configure;make;make install should handle 
> all the magic to get up and running from a tar.gz. Or much better a apt-get 
> install gnustep.

This. With the big caveat that DIY compilation is too hard for modern
Linux users. Ready-to-run binaries is the *only* way.

Some people seem to delight in themes to make it look just like Apple
macOS. That is a dangerous path. Remember what happened to PearOS:
bought out, shut down and archives deleted. Elementary only escaped
because it's not a very good copy!

Keep it looking like NeXTstep -- it's _still_ a strong look, a known
brand. Maybe modern themes. Make it respond to the same keystrokes as
macOS: none of this "alt-C" to copy nonsense. Either it's the Windows
way -- Ctrl-C, and conflict with Unix tradition, as KDE/GNOME/XFCE
etc. do -- or the Mac way: Super-C. But GNUstep *must* conform to the
existing norms, and it must exist as an easy-to-install binary
metapackage.

Ideally, IMHO, 2 metapackages: 1 for the desktop environment, 1 for
the dev tools.

-- 
Liam Proven - Profile: https://about.me/liamproven
Email: lpro...@cix.co.uk - Google Mail/Hangouts/Plus: lpro...@gmail.com
Twitter/Facebook/Flickr: lproven - Skype/LinkedIn: liamproven
UK: +44 7939-087884 - ČR (+ WhatsApp/Telegram/Signal): +420 702 829 053

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 27 Nov 2019, at 10:48, Johannes Brakensiek  
> wrote:
> 
> On 26 Nov 2019, at 23:43, Fred Kiefer wrote:
> 
> That could be said about all backward-compatibility. A follow up question
> is, does it hold us back enough to justify breaking compatibility? It seems
> some people think yes, and others think no. We're at a stalemate, where no
> progress can be expected to take place. For things to move forward, either
> one side has to give in, or both sides can compromise and agree to a middle
> ground.
> 
> You described the dilemma very well. (And I also want to thank David and Ivan 
> to their excellent contributions to this thread.) Some people are very 
> conservative in this group. But others have a bit too much wishful thinking. 
> I myself would not mind too much loosing gcc but loosing active developers 
> and packagers. Sadly for some this doesn’t seem to be an argument.
> 
> I think for those who have to do the decision (who’s that anyways, the active 
> contributors?) this probably will be good reason („argument“ ;)) as this is a 
> community of people working non-profit who seem to have strong feelings 
> regarding some options.
> 
> What I want to tell (being quite new to this community and not having these 
> strong bindings) is there are some reasons that are mainly considered outside 
> of this mailing list which should be important here as well, imho.
> 
> To name a few (just referring to what I’ve read, not meant as a personal 
> insult at all):
> 
> the GNUstep project is largely considered dead
> the only bigger free software project relying on GNUstep which seems to be of 
> greater relevance and extension is SOGo, which relies on Foundation and 
> GNUstep web, but not on AppKit (any of the devs active here?)
> German companies that used GNUstep told me they already switched to using 
> Foundation and GNUsteb web only as users did not accept the AppKit interface 
> anymore
> So, if people like the SOGo devs would say they need GCC because they are 
> relying on it and Foundation/GNUstep web, I’d say it would be a very 
> reasonable decision to keep Foundation and GNUstep web compatible to GCC.
> 
> But if there are no bigger projects depending on a GCC AppKit it should be a 
> first class aim of the project to develop it to a state that others would 
> consider picking it up and using it for their projects - imo. Yes, that’s 
> investing into future and it comes at the cost and risk of not being 
> successful, of course. But please bear in mind that probably there are a lot 
> more devs (here just being a few of them trying to give them a voice) that 
> evaluate which platform to use for their apps and probably pass by and choose 
> Qt or a web based platform.
> 
> I think that’s a pity as GNUstep AppKit could be highly attractive for Cocoa 
> ObjC devs wanting to port their apps to Linux and a free environment (and 
> maybe don’t want switch to Swift yet). If you don’t want that target audience 
> it’s your decision, but I’d be interested to know who’s your target audience 
> then? Of course you can do it just for yourself, but I think it’s unlikely 
> others will join then.
> 
> Johannes
> 

Thats a very good summary. For me  Foundation is what I use. But thats mainly 
because I do background server apps and tasks for Telecom Infrastructure. So I 
don't care about AppKit much right now. I care about a good and stable 
Objective-C development environment.

On the other hand I would _LOVE_ to see a OS X like desktop with AppKit and I 
would spend time working on it. Given the other desktops under Linux have not 
much success because of the way they do certain things, I think there is a big 
need. Something like what ElementaryOS does but with GNUStep and running on the 
major distributions (Debian/Ubuntu/Fedora/Redhat/Centos) could change the 
world. This is a long shot. But we have to ask ourselfs what is our strategy 
for the future.

Apple with Catalina is going in such a horrible direction that I'm moving away 
from it. My code can't run under Catalina because they have still not 
implemented SCTP protocol and its a mandatory for my work. And now the open 
source SCTP kernel driver can no longer work because they moved such stuff to 
userspace which kills a lot of mandatory features. So rewrite driver from 
scratch, just for MacOS whereas any other decent platform (Linux, FreeBSD) has 
it built in is an overkill.  And their Wallet garden approach is breaking lots 
of openSource apps etc. For example you can no logner write to /. So if your 
open source code uses /opt/something, youe dead as you can't create /opt etc 
etc. (but anyway, thats a rant for another day).

As far as Gnustep /App Kit goes, if the pillars below always fall apart, then 
its wasted time for any developer to work on it.  I think the key issues is 
that a lot of folks wanted to try GnuStep and fail because they could not get 
to some degree of success quickly. Everything is "old fashioned", doesnt 
compile 

Re: Which ObjC2.0 features are missing in the latest GCC?

[David Chisnall]

On 26/11/2019 22:43, Fred Kiefer wrote:

If I understand you correctly your suggestion is that we try to add support in 
gcc for some of the basic ObjC 2.0 features. That should be doable although the 
last time I tried I gave up on it. That was right after the Dublin meeting 
where we had a similar discussion to this one. The gcc people at that time 
where open to accept patches, but we should not expect too much help coming 
from their side. The reason I gave up was that at least a new version of the 
meta information that the compiler creates for the ObjC meta information was 
needed and I could not figure out a place where to flag that difference.


Please can people stop saying 'Objective-C 2'?  It's a marketing term 
that Apple used briefly and then dropped and has no relationship to any 
real definition of what the language means and does not appear on the 
Apple developer web site at all anymore.


Ian Sandoe was going to work on a better runtime abstraction layer for 
Objective-C in GCC.  He said he'd work on this two years ago, but 
doesn't seem to have made much progress, though he has done a little bit 
of work on improving the state of Apple runtime support.  His plan was 
to delay the runtime-specific lowering to the back end, which would be 
very nice and let LTO do some more interesting things.


Supporting a new ABI is much harder in GCC than Clang because of the 
history.  In GCC, the initial implementation supported only the NeXT 
runtime.  NeXT was forced to release this code via the threat of legal 
action and GCC was forced to merge the code to avoid looking stupid 
after forcing NeXT to release the code.  It was horrible code and if 
NeXT had open sourced it without the threat of legal action, I doubt GCC 
would have accepted it upstream.


Because GCC had the NeXT compiler code but no runtime support, they 
wrote an almost-compatible runtime and littered the code with `if 
(gnu_runtime)` blocks (I think, it might be `if (next_runtime)`.  NeXT / 
Apple never pulled in those changes and so merging from Apple's branch 
was always painful.


In contrast, Clang had no IR generation support when I started working 
on it.  I added an abstract class representing the runtime interfaces 
and a concrete subclass for the GCC and GNUstep runtimes.  Apple then 
maintained this because they were supporting various different runtime 
versions by this point and found the abstraction helpful.


Adding a new GCC-like runtime in clang involved simply creating a new 
subclass of this and overriding the things that had changed.  For GCC, 
it will involve untangling a load of spaghetti code.


It's probably a few months of work for someone with GCC experience to 
add support for the 2.0 ABI, though it's quite tangled with ARC if you 
wan it to actually be useful (for example, ivar metadata contains ARC 
ownership metadata now, which allows various reflection APIs to work 
correctly with ARC).


This is one of the current problems with the 'GNUstep doesn't use ARC, 
but it's fine with other things that do' approach: if you don't use ARC, 
you don't get ARC metadata, so things that use reflection don't work 
quite right from ARC.  You can't use weak properties from GNUstep.  For 
several release on macOS, things like the delegate of various NSView 
subclasses have been weak properties.  This means that modern Cocoa apps 
don't worry about ensuring that the delegate is removed from the view, 
they just rely on the runtime to handle this for them.


In GNUstep, if we wanted to depend on an ARC-supporting runtime but not 
compiler, then we *could* manually write the -setDelegate: and -delegate 
methods to call the relevant ARC functions, but:


 - The ivar would not be __weak and so access via reflection would 
break it.


 - The property metadata would not exist, so anything that depends on 
property metadata would break.


Modern Cocoa APIs are written assuming ARC and involve sublcassing 
classes that are expected to be compiled with ARC.  Over time, the 
work-arounds for the fact that GCC fundamentally does not support the 
same language that Cocoa was designed to work with are increasingly creaky.


TL;DR: Even with support for the new ABI, you still can't implement a 
fully Apple-compatible NSTableView and compile it with GCC.


David

Re: Which ObjC2.0 features are missing in the latest GCC?

[Johannes Brakensiek]

Gregory,

I’m leaving out your replies as it seems you did not get me right. 
First I was trying to strengthen your approach by reflecting the public 
opinion about GNUstep as far as I recognized it. Of course it is not 
fully true and of course I did not write and speak with everyone or did 
scientific research.


Second I was proposing a compromise of keeping base compatible to GCC 
and only update AppKit to the new runtime. But as you already wrote this 
does not seem to be sufficient.


If there are bigger free software projects using AppKit I’d be 
interested to know, btw.


The proposal of forking GNUstep and running two forks seems too much 
work to me and probably you won’t be able to port back what you’ve 
achieved using clang. So to me it seems you just have to decide if you 
start doing GNUstep 2.0 (breaking compatibility for new features, but 
keeping compatibility for older features of course - using clang you can 
compile everything you can with gcc, don’t you?). I don’t see a way 
of a compromise or middle ground.


Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?

[Gregory Casamento]

Johannes,

On Wed, Nov 27, 2019 at 4:49 AM Johannes Brakensiek <
johan...@brakensiek.info> wrote:

> On 26 Nov 2019, at 23:43, Fred Kiefer wrote:
>
> That could be said about all backward-compatibility. A follow up question
> is, does it hold us back enough to justify breaking compatibility? It seems
> some people think yes, and others think no. We're at a stalemate, where no
> progress can be expected to take place. For things to move forward, either
> one side has to give in, or both sides can compromise and agree to a middle
> ground.
>
> You described the dilemma very well. (And I also want to thank David and
> Ivan to their excellent contributions to this thread.) Some people are very
> conservative in this group. But others have a bit too much wishful
> thinking. I myself would not mind too much loosing gcc but loosing active
> developers and packagers. Sadly for some this doesn’t seem to be an
> argument.
>
> I think for those who have to do the decision (who’s that anyways, the
> active contributors?)
>
Yes.  More open source and free software projects are generally
"meritocracies."

> this probably will be good reason („argument“ ;)) as this is a community
> of people working non-profit who seem to have strong feelings regarding
> some options. What I want to tell (being quite new to this community and
> not having these strong bindings) is there are some reasons that are mainly
> considered outside of this mailing list which should be important here as
> well, imho.
>
To name a few (just referring to what I’ve read, not meant as a personal
> insult at all):
>
>- the GNUstep project is largely considered dead
>
> So was BSD at almost every writing since Linux was introduced.  As you
relatively new allow me to re-educate you as to it's deadness:
  * GNUstep is used on millions of android devices.  Two companies were
using it to port iOS games to android.  One was Apportable... the other is
their licensee PocketGems.  (I assisted Apportable with it's work)
  * GNUstep has been being used by eggplant.io who has large customers all
using the windows version of their software (which I helped to port there).
  * There is another company which uses GNUstep as part of it's data
collection framework.  It was part of an aerospace company called XCOR

So, in general, people who believe GNUstep is dead are misinformed.  Many
of these facts are listed on our wiki site so it's not like they are not
documented.   There are more examples I have only given the most relevant.

>
>- the only bigger free software project relying on GNUstep which seems
>to be of greater relevance and extension is SOGo, which relies on
>Foundation and GNUstep web, but not on AppKit (any of the devs active 
> here?)
>
> Sure, yeah... right.

>
>- German companies that used GNUstep told me they already switched to
>using Foundation and GNUsteb web only as users did not accept the AppKit
>interface anymore
>
> All German companies?  Maybe we should have you as a liaison to all of
them (joking), because there is one, called Algoriddim, which is using
GNUstep-base.  They don't use AppKit because they require UIKit, which we
don't yet have... but they are still using GNUstep and they have been an
immense help and a valuable contributor.

>
>
> So, if people like the SOGo devs would say they need GCC because they are
> relying on it and Foundation/GNUstep web, I’d say it would be a very
> reasonable decision to keep Foundation and GNUstep web compatible to GCC.
>
Thus Far in my work with Algoriddim and other companies, not having support
for some of these features is a huge issue.  For algoriddim alone I had to
implement a number of APIs which required blocks.

> But if there are no bigger projects depending on a GCC AppKit
>
There are... so the rest of this (your argument below is not relevant).
Also "GCC AppKit"?

> it should be a first class aim of the project to develop it to a state
> that others would consider picking it up and using it for their projects -
> imo. Yes, that’s investing into future and it comes at the cost and risk of
> not being successful, of course. But please bear in mind that probably
> there are a lot more devs (here just being a few of them trying to give
> them a voice) that evaluate which platform to use for their apps and
> probably pass by and choose Qt or a web based platform.
>
This is part of what I'm working towards.  Many projects want UIKit as
well.  AppKit is one focus of this project.

> I think that’s a pity as GNUstep AppKit could be highly attractive for
> Cocoa ObjC devs wanting to port their apps to Linux and a free environment
> (and maybe don’t want switch to Swift yet). If you don’t want that target
> audience it’s your decision, but I’d be interested to know who’s your
> target audience then?
>
I am THOROUGHLY confused.  You think that AppKit isn't part of our goal?
By what do you draw that conclusion?   There is no "Switching to swift"...
there is only 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Gregory Casamento]

Stefan,

On Tue, Nov 26, 2019 at 4:18 PM Stefan Bidigaray 
wrote:

> Hi Greg,
>
> On Tue, Nov 26, 2019 at 12:17 PM Gregory Casamento <
> greg.casame...@gmail.com> wrote:
>
>>
>> Stefan,
>>
>> I personally don't like off list discussions it makes things a little
>> more complicated than they need to be  that being said...
>>
>
> Yes... Only after I hit the send button did I realize I had not selected
> "Reply All". I'm adding mailing list back in so that folks can see your
> reply.
>

No worries.


> On Tue, Nov 26, 2019 at 10:43 AM Stefan Bidigaray 
>> wrote:
>>
>>> On Tue, Nov 26, 2019 at 4:55 AM Gregory Casamento <
>>> greg.casame...@gmail.com> wrote:
>>>

 I'd really like some resolution on this topic.   There seem to be a lot
 of reasons for and against.

 GC

>>>
>>> Hi Greg,
>>> I've managed to stay quiet throughout this discussion because I wanted
>>> to hear some of the arguments and counter-arguments before formulating my
>>> own opinion. As of this moment, I'm still not convinced that dropping GCC
>>> is a good choice.
>>>
>>> I believe dealing with an all-or-nothing option is not the right
>>> attitude. At the end of the day, completely dropping GCC is going to cause
>>> major disruption to the project. The fact is that some developers will be
>>> left out in the cold if/when this happens. Another argument is, for all
>>> it's flaws, GCC is the standard compiler on most Linux distributions (any
>>> of the ones using glibc, since it does not build with clang), so it is
>>> something that we get "for free".
>>>
>>
>> Indeed this is true.
>>
>>
>>> How about a compromise? How hard would it be for GCC to drop the GCC
>>> runtime in favor of GNUstep runtime, and implement everything except ARC
>>> and blocks (these seem to be the biggest road blocks)? While ARC and blocks
>>> are important for many developers, GNUstep itself is not directly dependent
>>> on the compiler supporting these features. Ideally, we could get to a
>>> situation where GCC and Clang compiled binaries can interoperate. Or am I
>>> way off?
>>>
>>
>> GNUstep is absolutely and TOTALLY dependent on the compiler for these
>> things.   ARC is done by the compiler at build time.  Blocks are also a
>> feature of the compiler.  GCC has neither of these features.
>>
>
> Let me clarify what I said... Currently, GNUstep does not require the
> compiler to support ARC nor blocks. Memory-management is currently done
> manually, and macros like CALL_BLOCK() allows us to call blocks without
> specifically requiring compiler support. While these 2 features are really
> nice, they would also require a lot of work to implement, as David pointed
> out.
>

Yes, and no.  There are many new APIs which require blocks. Memory
management could easily be done by ARC.  Right now it is done manually, but
look at it this way... base and gui can be used with both ARC and non-ARC
programs due to this fact.   Also CALL_BLOCK and DECLARE_BLOCK_* do not
allow us to use block under GCC.   They allow us a way to optionally
declare them in a way that they can be compiled out in GCC and declared
using clang.

>
>
>> One more questions... what do the GCC Objective-C maintainers have to say
>>> about this discussion? It would seem that GNUstep is now their only
>>> downstream "customer". Are they open to working with us to provide a more
>>> compatible compiler?
>>>
>>
>> They haven't seen this discussion.  They would likely expect us to make
>> these changes ourselves and, as David Chisnall pointed out... there is
>> about 2 man years of work there.
>>
>
> I completely understand that part. My suggestion was to How long would it
> take to implement all the language features, except ARC and blocks, in GCC?
> Could we implement the non-fragile ABI, @properties, generics, etc. in a
> reasonable amount of time? How hard to replace the GCC-runtime with the
> GNUstep-runtime? If this is more palatable, then is it a worthwhile avenue
> to pursue?
>

I believe earlier in this thread that David suggested that getting GCC up
to spec with clang would take somewhere near 2 man years.

My suggestion is, essentially, to get GCC to a more compatible position.
>

Indeed.   If gcc had better support I wouldn't have a problem with it.

At the end of the day, GNUstep has been around for a very long time, and
>>> like it or not, backward-compatibility is important. I personally believe,
>>> based on some of the discussion here, completely dropping GCC is going to
>>> be cause more problems than it solves. Whatever the decision, the
>>> implementation should be well planned and deliberate.
>>>
>>
>> I'm not so convinced.   GCC does nothing, but slow us down.
>>
>
> That could be said about all backward-compatibility. A follow up question
> is, does it hold us back enough to justify breaking compatibility?
>

I believe it does, but that is subjective.  As the API evolves blocks and
generics will become more and more ubiquitous.  Generics are not that much
of a 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Johannes Brakensiek]

On 26 Nov 2019, at 23:43, Fred Kiefer wrote:

That could be said about all backward-compatibility. A follow up 
question
is, does it hold us back enough to justify breaking compatibility? 
It seems
some people think yes, and others think no. We're at a stalemate, 
where no
progress can be expected to take place. For things to move forward, 
either
one side has to give in, or both sides can compromise and agree to a 
middle

ground.




You described the dilemma very well. (And I also want to thank David 
and Ivan to their excellent contributions to this thread.) Some people 
are very conservative in this group. But others have a bit too much 
wishful thinking. I myself would not mind too much loosing gcc but 
loosing active developers and packagers. Sadly for some this doesn’t 
seem to be an argument.


I think for those who have to do the decision (who’s that anyways, the 
active contributors?) this probably will be good reason („argument“ 
;)) as this is a community of people working non-profit who seem to have 
strong feelings regarding some options.


What I want to tell (being quite new to this community and not having 
these strong bindings) is there are some reasons that are mainly 
considered outside of this mailing list which should be important here 
as well, imho.


To name a few (just referring to what I’ve read, not meant as a 
personal insult at all):


- the GNUstep project is largely considered dead
- the only bigger free software project relying on GNUstep which seems 
to be of greater relevance and extension is SOGo, which relies on 
Foundation and GNUstep web, but not on AppKit (any of the devs active 
here?)
- German companies that used GNUstep told me they already switched to 
using Foundation and GNUsteb web only as users did not accept the AppKit 
interface anymore


So, if people like the SOGo devs would say they need GCC because they 
are relying on it and Foundation/GNUstep web, I’d say it would be a 
very reasonable decision to keep Foundation and GNUstep web compatible 
to GCC.


But if there are no bigger projects depending on a GCC AppKit it should 
be a first class aim of the project to develop it to a state that others 
would consider picking it up and using it for their projects - imo. Yes, 
that’s investing into future and it comes at the cost and risk of not 
being successful, of course. But please bear in mind that probably there 
are a lot more devs (here just being a few of them trying to give them a 
voice) that evaluate which platform to use for their apps and probably 
pass by and choose Qt or a web based platform.


I think that’s a pity as GNUstep AppKit could be highly attractive for 
Cocoa ObjC devs wanting to port their apps to Linux and a free 
environment (and maybe don’t want switch to Swift yet). If you don’t 
want that target audience it’s your decision, but I’d be interested 
to know who’s your target audience then? Of course you can do it just 
for yourself, but I think it’s unlikely others will join then.


Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?

[Maxthon Chan]

When talking about SwiftUI, I mean having CAAppKitBridge/Opal/Back implement 
SwiftUI API as its interface to the upper layers. This gives us both a partial 
SwiftUI implementation that will be useable when we get Swift interop, and a 
common denominator where both AppKit and UIKit can stand on. Then we can have, 
for example, NSView and UIView both implemented based on SUIView. (SwiftUI 
classes lacked prefixes, so for the Objective-C based partial implementation I 
am suggesting adding SUI as the prefix.)

As of Swift interop itself, the main hurdle is ABI. I don’t think GCC can even 
emit code in either GNUstep runtime or Apple Swift runtime and their ABIs, so 
that is why a GCC-built GNUstep have no hope at attempting Swift interop. 
Apple-released Swift compiler have interop code in its source tree but it is 
disabled outside macOS. What we need is somehow patch it to enable interop, 
choose which libobjc, Foundation and CoreFoundation to use (either patch our 
own version, or throw out our own code and use Apple’s version,) and then 
somehow figure out how to make it work with the rest of GNUstep code.

While the high level API for libclang is C, I think Xcode uses a bit more than 
those and taps into the C++ part, so C++ is needed.

> On Nov 27, 2019, at 6:04 AM, Ivan Vučica  wrote:
> 
> On Tue, Nov 26, 2019 at 3:49 PM Maxthon Chan  wrote:
>> 
>> AppKit on CoreAnimation can be our first big piece of fully ARC code. I 
>> don’t think anything in AppKit would require special memory handling, so it 
>> should be able to be fully ARC'd. Just by enabling ARC and @properties we 
>> get a lot of potential bugs out of the system.
> 
> Can you share your design for how AppKit on Core Animation would work
> in GNUstep?
> 
> Because ARC would not help with the design we went with during GSoC
> 2018 -- see 
> https://github.com/gnustep/libs-quartzcore/tree/master/CAAppKitBridge
> and related changes in -gui etc. The issues were not due to ARC and
> @properties (with @properties actually being available on recent GCCs,
> I think). The issues were, if I remember correctly, due to things
> getting painted in the wrong location, with some properties being
> reset at the wrong time, et cetera. Very frustrating for student,
> myself and (I hope I'm not speaking out of order) Fred.
> 
> Therefore, do you have a different proposal on how AppKit should paint
> onto a CALayer, with a root CALayer being painted onto the screen?
> 
>> Actually if UIKit is in the plans,
> 
> Your phrasing brings some joy when I'm looking at the English idiom
> "in the plans" :-)
> 
> As in -- there are plans, as in "we have at least two options on how
> to proceed", but nobody has committed to working on either.
> 
> Two options that come to mind:
> 
> 1. carefully implement UIEvent+UIApplicationMain, then
> UIView+UIWindow, then UIButton, then UITableViewController, then
> UINavigationController, carefully segregating window+GL context+event
> pump functionality into backends (like on gnustep-gui)
> 2. finish CAAppKitBridge, then port Chameleon, improving
> AppKit+CA+Chameleon along the way
> 
> I'd say that finishing CAAppKitBridge is good anyway, while
> implementing UI* classes from scratch is certainly a fun activity (and
> one that might be easier to put on mobile platforms, for instance on
> Sailfish).
> 
>> before working on AppKit I would suggest working on SwiftUI first (at least 
>> a Objective-C based subset of it that can result in the correct Swift 
>> interface when we get Swift interworking) and build AppKit and UIKit on top 
>> of that. (This is like Apple using CoreFoundation as a common denominator 
>> between Carbon and Foundation, I am suggesting using a partial SwiftUI as 
>> the common denominator between AppKit and UIKit.)
> 
> I can tell you for sure that I am personally completely unfamiliar
> with SwiftUI, and almost completely unfamiliar with Swift itself, so I
> can only comment on what I'd do to switch AppKit to Core Animation,
> and what I'd do to start writing UIKit. Whoever wishes to address this
> before I get around to it, reach out to me.
> 
> If someone wants to tackle SwiftUI before finishing CAAppKitBridge,
> I'm afraid I'd be useless. Maybe there's someone in the community that
> could help with this activity?
> 
>> Also if we get that improved C++ support, we can start working on a better 
>> IDE and build system that is comparable to Xcode.
> 
> Why is C++ support a requirement for working on a better IDE?
> 
>> Modern Xcode uses libclang and libllvm for code highlighting and code 
>> sensing, so that is why Objective-C++ is needed,
> 
> Unless libclang's API changed significantly since I used it in 2013 at
> university, Objective-C++ is not a requirement for code highlighting
> and code sensing. I'm looking at my old code in a .m file and the API
> is raw C.
> 
>> and it is also a huge piece of ARC code (Apple made a point when they 
>> converted Xcode from GC to ARC in Xcode 5.)
> 
> Which huge 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Fred Kiefer]

> Am 26.11.2019 um 22:18 schrieb Stefan Bidigaray :
> On Tue, Nov 26, 2019 at 12:17 PM Gregory Casamento  
> wrote:
> > One more questions... what do the GCC Objective-C maintainers have to say
>> >> about this discussion? It would seem that GNUstep is now their only
>> >> downstream "customer". Are they open to working with us to provide a more
>> >> compatible compiler?
>> >>
>> >
>> > They haven't seen this discussion.  They would likely expect us to make
>> > these changes ourselves and, as David Chisnall pointed out... there is
>> > about 2 man years of work there.
>> 
>> I completely understand that part. My suggestion was to How long would it
>> take to implement all the language features, except ARC and blocks, in GCC?
>> Could we implement the non-fragile ABI, @properties, generics, etc. in a
>> reasonable amount of time? How hard to replace the GCC-runtime with the
>> GNUstep-runtime? If this is more palatable, then is it a worthwhile avenue
>> to pursue?
>> 
>> My suggestion is, essentially, to get GCC to a more compatible position.

If I understand you correctly your suggestion is that we try to add support in 
gcc for some of the basic ObjC 2.0 features. That should be doable although the 
last time I tried I gave up on it. That was right after the Dublin meeting 
where we had a similar discussion to this one. The gcc people at that time 
where open to accept patches, but we should not expect too much help coming 
from their side. The reason I gave up was that at least a new version of the 
meta information that the compiler creates for the ObjC meta information was 
needed and I could not figure out a place where to flag that difference.

>> > At the end of the day, GNUstep has been around for a very long time, and
>> >> like it or not, backward-compatibility is important. I personally believe,
>> >> based on some of the discussion here, completely dropping GCC is going to
>> >> be cause more problems than it solves. Whatever the decision, the
>> >> implementation should be well planned and deliberate.
>> >>
>> >
>> > I'm not so convinced.   GCC does nothing, but slow us down.
>> >
>> 
>> That could be said about all backward-compatibility. A follow up question
>> is, does it hold us back enough to justify breaking compatibility? It seems
>> some people think yes, and others think no. We're at a stalemate, where no
>> progress can be expected to take place. For things to move forward, either
>> one side has to give in, or both sides can compromise and agree to a middle
>> ground.

You described the dilemma very well. (And I also want to thank David and Ivan 
to their excellent contributions to this thread.) Some people are very 
conservative in this group. But others have a bit too much wishful thinking. I 
myself would not mind too much loosing gcc but loosing active developers and 
packagers. Sadly for some this doesn’t seem to be an argument.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Ivan Vučica]

On Tue, Nov 26, 2019 at 3:49 PM Maxthon Chan  wrote:
>
> AppKit on CoreAnimation can be our first big piece of fully ARC code. I don’t 
> think anything in AppKit would require special memory handling, so it should 
> be able to be fully ARC'd. Just by enabling ARC and @properties we get a lot 
> of potential bugs out of the system.

Can you share your design for how AppKit on Core Animation would work
in GNUstep?

Because ARC would not help with the design we went with during GSoC
2018 -- see 
https://github.com/gnustep/libs-quartzcore/tree/master/CAAppKitBridge
and related changes in -gui etc. The issues were not due to ARC and
@properties (with @properties actually being available on recent GCCs,
I think). The issues were, if I remember correctly, due to things
getting painted in the wrong location, with some properties being
reset at the wrong time, et cetera. Very frustrating for student,
myself and (I hope I'm not speaking out of order) Fred.

Therefore, do you have a different proposal on how AppKit should paint
onto a CALayer, with a root CALayer being painted onto the screen?

> Actually if UIKit is in the plans,

Your phrasing brings some joy when I'm looking at the English idiom
"in the plans" :-)

As in -- there are plans, as in "we have at least two options on how
to proceed", but nobody has committed to working on either.

Two options that come to mind:

1. carefully implement UIEvent+UIApplicationMain, then
UIView+UIWindow, then UIButton, then UITableViewController, then
UINavigationController, carefully segregating window+GL context+event
pump functionality into backends (like on gnustep-gui)
2. finish CAAppKitBridge, then port Chameleon, improving
AppKit+CA+Chameleon along the way

I'd say that finishing CAAppKitBridge is good anyway, while
implementing UI* classes from scratch is certainly a fun activity (and
one that might be easier to put on mobile platforms, for instance on
Sailfish).

> before working on AppKit I would suggest working on SwiftUI first (at least a 
> Objective-C based subset of it that can result in the correct Swift interface 
> when we get Swift interworking) and build AppKit and UIKit on top of that. 
> (This is like Apple using CoreFoundation as a common denominator between 
> Carbon and Foundation, I am suggesting using a partial SwiftUI as the common 
> denominator between AppKit and UIKit.)

I can tell you for sure that I am personally completely unfamiliar
with SwiftUI, and almost completely unfamiliar with Swift itself, so I
can only comment on what I'd do to switch AppKit to Core Animation,
and what I'd do to start writing UIKit. Whoever wishes to address this
before I get around to it, reach out to me.

If someone wants to tackle SwiftUI before finishing CAAppKitBridge,
I'm afraid I'd be useless. Maybe there's someone in the community that
could help with this activity?

> Also if we get that improved C++ support, we can start working on a better 
> IDE and build system that is comparable to Xcode.

Why is C++ support a requirement for working on a better IDE?

> Modern Xcode uses libclang and libllvm for code highlighting and code 
> sensing, so that is why Objective-C++ is needed,

Unless libclang's API changed significantly since I used it in 2013 at
university, Objective-C++ is not a requirement for code highlighting
and code sensing. I'm looking at my old code in a .m file and the API
is raw C.

> and it is also a huge piece of ARC code (Apple made a point when they 
> converted Xcode from GC to ARC in Xcode 5.)

Which huge piece of ARC code are you referring to that we can use?

> As of our replacement xcode-build and IDEKit (the library parsing xcodeproj 
> bundles) that can also be a huge piece of ARC code.

This is a different problem. It *can* be, it doesn't have to be.

Plus, an improved editor doesn't *need* to be Xcode-compatible or able
to read Xcode project files (though it's a nice bonus).

> And there is Swift interworking since I mentioned SwiftUI, which requires 
> clang.

This, again, does not mean GS core *needs* to depend on Clang. Does
Swift interop (which, if it's available on non-Apple platforms, I'd
love to familiarize myself with) actually require such changes to
GNUstep's headers and implementation that we cannot segregate it from
the rest of GS?

David's argument (as far as I understand it -- he can correct me) is
that many things become simpler to implement if we use Objective-C++
and ARC. And if we adopt it, I accept that it's far easier to delete
the older implementations of the functionality -- the implementations
which require neither ARC or Objective-C++. This is indeed very
appealing.

However, I remain unconvinced that we *have* to remove the old code
and that it's such a heavy burden to have a version for the GCC
runtime and GCC and a version for libobjc2 and Clang.

(And, of course, this is a separate issue from how binaries --
including developer 'binaries', such as Debian's configuration for
building GNUstep software 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Stefan Bidigaray]

Hi Greg,

On Tue, Nov 26, 2019 at 12:17 PM Gregory Casamento 
wrote:

>
> Stefan,
>
> I personally don't like off list discussions it makes things a little more
> complicated than they need to be  that being said...
>

Yes... Only after I hit the send button did I realize I had not selected
"Reply All". I'm adding mailing list back in so that folks can see your
reply.


> On Tue, Nov 26, 2019 at 10:43 AM Stefan Bidigaray 
> wrote:
>
>> On Tue, Nov 26, 2019 at 4:55 AM Gregory Casamento <
>> greg.casame...@gmail.com> wrote:
>>
>>>
>>> I'd really like some resolution on this topic.   There seem to be a lot
>>> of reasons for and against.
>>>
>>> GC
>>>
>>
>> Hi Greg,
>> I've managed to stay quiet throughout this discussion because I wanted to
>> hear some of the arguments and counter-arguments before formulating my own
>> opinion. As of this moment, I'm still not convinced that dropping GCC is a
>> good choice.
>>
>> I believe dealing with an all-or-nothing option is not the right
>> attitude. At the end of the day, completely dropping GCC is going to cause
>> major disruption to the project. The fact is that some developers will be
>> left out in the cold if/when this happens. Another argument is, for all
>> it's flaws, GCC is the standard compiler on most Linux distributions (any
>> of the ones using glibc, since it does not build with clang), so it is
>> something that we get "for free".
>>
>
> Indeed this is true.
>
>
>> How about a compromise? How hard would it be for GCC to drop the GCC
>> runtime in favor of GNUstep runtime, and implement everything except ARC
>> and blocks (these seem to be the biggest road blocks)? While ARC and blocks
>> are important for many developers, GNUstep itself is not directly dependent
>> on the compiler supporting these features. Ideally, we could get to a
>> situation where GCC and Clang compiled binaries can interoperate. Or am I
>> way off?
>>
>
> GNUstep is absolutely and TOTALLY dependent on the compiler for these
> things.   ARC is done by the compiler at build time.  Blocks are also a
> feature of the compiler.  GCC has neither of these features.
>

Let me clarify what I said... Currently, GNUstep does not require the
compiler to support ARC nor blocks. Memory-management is currently done
manually, and macros like CALL_BLOCK() allows us to call blocks without
specifically requiring compiler support. While these 2 features are really
nice, they would also require a lot of work to implement, as David pointed
out.


> One more questions... what do the GCC Objective-C maintainers have to say
>> about this discussion? It would seem that GNUstep is now their only
>> downstream "customer". Are they open to working with us to provide a more
>> compatible compiler?
>>
>
> They haven't seen this discussion.  They would likely expect us to make
> these changes ourselves and, as David Chisnall pointed out... there is
> about 2 man years of work there.
>

I completely understand that part. My suggestion was to How long would it
take to implement all the language features, except ARC and blocks, in GCC?
Could we implement the non-fragile ABI, @properties, generics, etc. in a
reasonable amount of time? How hard to replace the GCC-runtime with the
GNUstep-runtime? If this is more palatable, then is it a worthwhile avenue
to pursue?

My suggestion is, essentially, to get GCC to a more compatible position.


> At the end of the day, GNUstep has been around for a very long time, and
>> like it or not, backward-compatibility is important. I personally believe,
>> based on some of the discussion here, completely dropping GCC is going to
>> be cause more problems than it solves. Whatever the decision, the
>> implementation should be well planned and deliberate.
>>
>
> I'm not so convinced.   GCC does nothing, but slow us down.
>

That could be said about all backward-compatibility. A follow up question
is, does it hold us back enough to justify breaking compatibility? It seems
some people think yes, and others think no. We're at a stalemate, where no
progress can be expected to take place. For things to move forward, either
one side has to give in, or both sides can compromise and agree to a middle
ground.


> Stefan
>>
>
> Yours, GC
>
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> http://ind.ie/phoenix/
>

Stefan

>

Re: Which ObjC2.0 features are missing in the latest GCC?

[Maxthon Chan]

AppKit on CoreAnimation can be our first big piece of fully ARC code. I don’t 
think anything in AppKit would require special memory handling, so it should be 
able to be fully ARC'd. Just by enabling ARC and @properties we get a lot of 
potential bugs out of the system.

Actually if UIKit is in the plans, before working on AppKit I would suggest 
working on SwiftUI first (at least a Objective-C based subset of it that can 
result in the correct Swift interface when we get Swift interworking) and build 
AppKit and UIKit on top of that. (This is like Apple using CoreFoundation as a 
common denominator between Carbon and Foundation, I am suggesting using a 
partial SwiftUI as the common denominator between AppKit and UIKit.)

Also if we get that improved C++ support, we can start working on a better IDE 
and build system that is comparable to Xcode. Modern Xcode uses libclang and 
libllvm for code highlighting and code sensing, so that is why Objective-C++ is 
needed, and it is also a huge piece of ARC code (Apple made a point when they 
converted Xcode from GC to ARC in Xcode 5.) As of our replacement xcode-build 
and IDEKit (the library parsing xcodeproj bundles) that can also be a huge 
piece of ARC code.

And there is Swift interworking since I mentioned SwiftUI, which requires clang.

> On Nov 26, 2019, at 11:15 PM, Ivan Vučica  wrote:
> 
> On Tue 26 Nov 2019 at 14:43, Pirmin Braun  > wrote:
> 
> a modern Objective-C Ecosystem, comparable to iOS and XCode from Apple, the 
> well known market leader, blah blah
> 
> making it a perfect porting target for iOS applications to run on any cheap 
> laptop with any Linux distribution
> 
> Correctly implemented library compatible-with-UIKit is a massive undertaking. 
> Switching compilers won’t fix this or speed it up greatly. 
> 
> It might attract new people who would more easily take a look at it, but, 
> honestly, given the amount of effort, MRC is comparably not going to be the 
> problem here.
> 
> Core Animation-compatible implementation needs more work, as does Opal (Core 
> Graphics). And if you just want to do what was planned years ago — adapt 
> Chameleon to GNUstep’s AppKit — you still need to finish the CA-AppKit 
> integration work.
> 
> These things are not enabled by switching to Clang, they are possible with 
> GCC with similar amount of effort as working in a possible Clang fork. Only 
> one thing comes to mind that is enabled by Clang+libobjc2: @dynamic 
> properties in Core Animation (but, only if you care about @dynamic animatable 
> properties being done well).
> 
> So let’s not drag iOS into the story. ARC, ObjC++ and other language features 
> are what’s addressable here, and whether core GS should allow this.
> 
> -- 
> Sent from Gmail Mobile

Re: Which ObjC2.0 features are missing in the latest GCC?

[Stefan Bidigaray]

On Tue, Nov 26, 2019 at 4:55 AM Gregory Casamento 
wrote:

>
> I'd really like some resolution on this topic.   There seem to be a lot of
> reasons for and against.
>
> GC
>

Hi Greg,
I've managed to stay quiet throughout this discussion because I wanted to
hear some of the arguments and counter-arguments before formulating my own
opinion. As of this moment, I'm still not convinced that dropping GCC is a
good choice.

I believe dealing with an all-or-nothing option is not the right attitude.
At the end of the day, completely dropping GCC is going to cause major
disruption to the project. The fact is that some developers will be left
out in the cold if/when this happens. Another argument is, for all it's
flaws, GCC is the standard compiler on most Linux distributions (any of the
ones using glibc, since it does not build with clang), so it is something
that we get "for free".

How about a compromise? How hard would it be for GCC to drop the GCC
runtime in favor of GNUstep runtime, and implement everything except ARC
and blocks (these seem to be the biggest road blocks)? While ARC and blocks
are important for many developers, GNUstep itself is not directly dependent
on the compiler supporting these features. Ideally, we could get to a
situation where GCC and Clang compiled binaries can interoperate. Or am I
way off?

One more questions... what do the GCC Objective-C maintainers have to say
about this discussion? It would seem that GNUstep is now their only
downstream "customer". Are they open to working with us to provide a more
compatible compiler?

At the end of the day, GNUstep has been around for a very long time, and
like it or not, backward-compatibility is important. I personally believe,
based on some of the discussion here, completely dropping GCC is going to
be cause more problems than it solves. Whatever the decision, the
implementation should be well planned and deliberate.

Stefan

>

Re: Which ObjC2.0 features are missing in the latest GCC?

[Ivan Vučica]

On Tue 26 Nov 2019 at 14:43, Pirmin Braun  wrote:

>
> a modern Objective-C Ecosystem, comparable to iOS and XCode from Apple,
> the well known market leader, blah blah
>
> making it a perfect porting target for iOS applications to run on any
> cheap laptop with any Linux distribution


Correctly implemented library compatible-with-UIKit is a massive
undertaking. Switching compilers won’t fix this or speed it up greatly.

It might attract new people who would more easily take a look at it, but,
honestly, given the amount of effort, MRC is comparably not going to be the
problem here.

Core Animation-compatible implementation needs more work, as does Opal
(Core Graphics). And if you just want to do what was planned years ago —
adapt Chameleon to GNUstep’s AppKit — you still need to finish the
CA-AppKit integration work.

These things are not enabled by switching to Clang, they are possible with
GCC with similar amount of effort as working in a possible Clang fork. Only
one thing comes to mind that is enabled by Clang+libobjc2: @dynamic
properties in Core Animation (but, only if you care about @dynamic
animatable properties being done well).

So let’s not drag iOS into the story. ARC, ObjC++ and other language
features are what’s addressable here, and whether core GS should allow this.

-- 
Sent from Gmail Mobile

Re: Which ObjC2.0 features are missing in the latest GCC?

[hasebastian]

Hello,

i don't think there is a need for a new name (in case there will indeed 
be a major breaking change). I suggest to adapt semantic versioning and 
use the major version number in the package names, so that all GNUstep 
versions can be installed in parallel. Just as e.g. qt or gtk are doing 
it.


Sebastian

Re: Which ObjC2.0 features are missing in the latest GCC?

[Umberto Cerrato]

I would like to get involved in these choices... like name ideas etc. please 
make something more “open” (f.e. a poll/Doodle ...)

Also... you write a lot! Here on the mailing list.
IDK how you do to keep yourself up-to-date...

This is just a feedback from a new-subscriber point of view... I do not know if 
you can help me with this.

Best

> Il giorno 26 nov 2019, alle ore 15:43, Pirmin Braun  ha scritto:
> 
> ah, what's in a name...
> 
> "Next" and "step" are from NeXTSTEP, an ancient Operating System from 1987, 
> running on stylish 680030 NeXT Hardware like the NeXTStation, no one knows 
> today
> 
> "GNU" is from GNU which is Not Unix so you get asked "what's so bad about 
> Unix?"
> 
> what will we have?
> 
> a modern Objective-C Ecosystem, comparable to iOS and XCode from Apple, the 
> well known market leader, blah blah
> 
> making it a perfect porting target for iOS applications to run on any cheap 
> laptop with any Linux distribution 
> 
> or for rapid development of stunning server applications and deployment on 
> all sorts of *ix operating systems and covering all hardware from the 
> Raspberry PI up to the AWS or Azure server farms
> 
> now, how to put this in a word?
> 
> On Tue, 26 Nov 2019 15:15:01 +0100
> Andreas Fink  wrote:
> 
>> 
>> 
>>> On 26 Nov 2019, at 15:06, H. Nikolaus Schaller  wrote:
>>> 
>>> 
 Am 26.11.2019 um 11:09 schrieb Pirmin Braun :
 
 I'd suggest a fork, i.e. "Gnustep2" with LLVM, Clang, libobjc2 
>>> 
>>> just came to my mind: ClangSTEP?
>> 
>> 
>> what a tong breaker. FreeStep sounds better to me :)
>> Drop the "GNU" and break free.
>> 
>> 
>>> 
 
 On Tue, 26 Nov 2019 04:55:43 -0500
 Gregory Casamento  wrote:
 
> I'd really like some resolution on this topic.   There seem to be a lot of
> reasons for and against.
> 
> GC
> 
> On Mon, Nov 25, 2019 at 1:04 PM David Chisnall 
> wrote:
> 
>>> On 25 Nov 2019, at 14:07, H. Nikolaus Schaller  
>>> wrote:
>>> I am not sure that this is the only way to implement it.
>>> 
>>> First of all the callMethodOn returns some block which is a data
>> structure knowing that it should take the parameter x and do some 
>> function.
>>> Let's call it NSBlock. NSBlock can be an ordinary object like any other
>> so that it can follow the same memory management rules as used otherwise.
>> 
>> That’s shifting the goalposts somewhat.  It is not news that objects and
>> closures are equivalent.  Smalltalk implemented blocks as BlockClosure
>> objects, Ian Piumarta’s Composite Object-Lambda Architecture, and C++
>> lambdas (which are just shorthand for C++ objects that implement
>> `operator()`).  You can always express anything that uses blocks with
>> objects.
>> 
>> There are two issues:
>> 
>> 1. If you want to be compatible with existing APIs that use blocks, you
>> need to be ABI compatible with blocks.
>> 2. The reason that most languages that have objects also have blocks is
>> that the shorthand syntax is very convenient.
>> 
>> The following are roughly equivalent:
>> 
>> ```
>> @interface Delegate : NSObject
>> - (void)invoke;
>> - (instancetype)initWithCapture: (id)someObject;
>> @end
>> 
>> @implementation Delegate
>> {
>>  @private
>>  id obj;
>> }
>> - (instancetype)initWithCapture: (id)someObject
>> {
>>  if ((self = [super init]) == nil) return nil;
>>  obj = [someObject retain];
>>  return self;
>> }
>> - (void)invoke
>> {
>>  [obj doSomething];
>> }
>> - (void)dealloc
>> {
>>  [obj release];
>>  [super dealloc];
>> }
>> @end
>> 
>> // At construction site:
>> 
>> [[Delegate alloc] initWithCapture: x];
>> 
>> // At use site:
>> 
>> [delegate invoke];
>> ```
>> 
>> And this, with blocks:
>> 
>> ```
>> // At construction site:
>> 
>> ^() { [x doSomething]; };
>> 
>> // At use site:
>> 
>> delegate();
>> ```
>> 
>> At use, these are similar complexity for the programmer.  At the point of
>> construction, one is one line of code (two or three if you put lambda
>> bodies on their own lines), the other is 26.  As a programmer, I don’t 
>> want
>> to write 26 lines of code for a one-line callback.
>> 
>> In C++98 you could probably template that and provide a generic class 
>> that
>> took a struct containing the captures and a C function, so you’d get a 
>> lot
>> less boilerplate.  Assuming you had fudged ARC like this (as above, this
>> code is typed into a mail client and probably doesn’t compile):
>> 
>> ```
>> template
>> struct ObjCObjectWrapper
>> {
>>  ObjCObjectWrapper(T x) : obj(objc_retain(x)) {}
>>  ObjCObjectWrapper(const ObjCObjectWrapper ) :
>> 

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 26.11.2019 um 15:15 schrieb Andreas Fink :
> 
> 
> 
>> On 26 Nov 2019, at 15:06, H. Nikolaus Schaller  wrote:
>> 
>> 
>>> Am 26.11.2019 um 11:09 schrieb Pirmin Braun :
>>> 
>>> I'd suggest a fork, i.e. "Gnustep2" with LLVM, Clang, libobjc2 
>> 
>> just came to my mind: ClangSTEP?
> 
> 
> what a tong breaker. FreeStep sounds better to me :)
> Drop the "GNU" and break free.

Hm.

I do not understand the rationale: why do you want to break free from GNU?

I only understand the whole discussion as: some of us want to break free
from GCC which is "GNU Compiler Collection" and replace it by Clang for
technical reasons (more modern features, easier maintenance). Not for
freedom reasons.

GNU is already fully Free Software and GNUstep is as well.

So "FreeStep" directs in the wrong direction, IMHO.

All that is indeed only relevant, if it is really wise to fork into two
sister projects. Which I heavily doubt. It is probably easier to handle
two GNUstep flavors under a single umbrella. Or as what I am advocating
for is to continue to support both compiler suites in a single project.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Pirmin Braun]

ah, what's in a name...

"Next" and "step" are from NeXTSTEP, an ancient Operating System from 1987, 
running on stylish 680030 NeXT Hardware like the NeXTStation, no one knows today

"GNU" is from GNU which is Not Unix so you get asked "what's so bad about Unix?"

what will we have?

a modern Objective-C Ecosystem, comparable to iOS and XCode from Apple, the 
well known market leader, blah blah

making it a perfect porting target for iOS applications to run on any cheap 
laptop with any Linux distribution 

or for rapid development of stunning server applications and deployment on all 
sorts of *ix operating systems and covering all hardware from the Raspberry PI 
up to the AWS or Azure server farms

now, how to put this in a word?

On Tue, 26 Nov 2019 15:15:01 +0100
Andreas Fink  wrote:

> 
> 
> > On 26 Nov 2019, at 15:06, H. Nikolaus Schaller  wrote:
> > 
> > 
> >> Am 26.11.2019 um 11:09 schrieb Pirmin Braun :
> >> 
> >> I'd suggest a fork, i.e. "Gnustep2" with LLVM, Clang, libobjc2 
> > 
> > just came to my mind: ClangSTEP?
> 
> 
> what a tong breaker. FreeStep sounds better to me :)
> Drop the "GNU" and break free.
> 
> 
> > 
> >> 
> >> On Tue, 26 Nov 2019 04:55:43 -0500
> >> Gregory Casamento  wrote:
> >> 
> >>> I'd really like some resolution on this topic.   There seem to be a lot of
> >>> reasons for and against.
> >>> 
> >>> GC
> >>> 
> >>> On Mon, Nov 25, 2019 at 1:04 PM David Chisnall 
> >>> wrote:
> >>> 
>  On 25 Nov 2019, at 14:07, H. Nikolaus Schaller  
>  wrote:
> > I am not sure that this is the only way to implement it.
> > 
> > First of all the callMethodOn returns some block which is a data
>  structure knowing that it should take the parameter x and do some 
>  function.
> > Let's call it NSBlock. NSBlock can be an ordinary object like any other
>  so that it can follow the same memory management rules as used otherwise.
>  
>  That’s shifting the goalposts somewhat.  It is not news that objects and
>  closures are equivalent.  Smalltalk implemented blocks as BlockClosure
>  objects, Ian Piumarta’s Composite Object-Lambda Architecture, and C++
>  lambdas (which are just shorthand for C++ objects that implement
>  `operator()`).  You can always express anything that uses blocks with
>  objects.
>  
>  There are two issues:
>  
>  1. If you want to be compatible with existing APIs that use blocks, you
>  need to be ABI compatible with blocks.
>  2. The reason that most languages that have objects also have blocks is
>  that the shorthand syntax is very convenient.
>  
>  The following are roughly equivalent:
>  
>  ```
>  @interface Delegate : NSObject
>  - (void)invoke;
>  - (instancetype)initWithCapture: (id)someObject;
>  @end
>  
>  @implementation Delegate
>  {
>    @private
>    id obj;
>  }
>  - (instancetype)initWithCapture: (id)someObject
>  {
>    if ((self = [super init]) == nil) return nil;
>    obj = [someObject retain];
>    return self;
>  }
>  - (void)invoke
>  {
>    [obj doSomething];
>  }
>  - (void)dealloc
>  {
>    [obj release];
>    [super dealloc];
>  }
>  @end
>  
>  // At construction site:
>  
>  [[Delegate alloc] initWithCapture: x];
>  
>  // At use site:
>  
>  [delegate invoke];
>  ```
>  
>  And this, with blocks:
>  
>  ```
>  // At construction site:
>  
>  ^() { [x doSomething]; };
>  
>  // At use site:
>  
>  delegate();
>  ```
>  
>  At use, these are similar complexity for the programmer.  At the point of
>  construction, one is one line of code (two or three if you put lambda
>  bodies on their own lines), the other is 26.  As a programmer, I don’t 
>  want
>  to write 26 lines of code for a one-line callback.
>  
>  In C++98 you could probably template that and provide a generic class 
>  that
>  took a struct containing the captures and a C function, so you’d get a 
>  lot
>  less boilerplate.  Assuming you had fudged ARC like this (as above, this
>  code is typed into a mail client and probably doesn’t compile):
>  
>  ```
>  template
>  struct ObjCObjectWrapper
>  {
>    ObjCObjectWrapper(T x) : obj(objc_retain(x)) {}
>    ObjCObjectWrapper(const ObjCObjectWrapper ) :
>  obj(objc_retain(other.obj) {}
>    ObjCObjectWrapper(ObjCObjectWrapper &) : obj(other.obj)
>    {
>    other.obj = nil;
>    }
>    ObjCObjectWrapper()
>    {
>    objc_release(obj);
>    }
>    operator=(T x)
>    {
>    objc_storeStrong(, x);
>    }
>    T operator()
>    {
>    return obj;
>    }
>    

RE: Which ObjC2.0 features are missing in the latest GCC?

[Max Chan]

I would suggest forking as a last resort. Don't take it easily, however if it 
can not be resolved in any other way, I am not against it.

As of name, I suggest Linnaeus. First off it does not contain the string GNU so 
no risk of trademark. Then the name Linnaeus, as in Carl, is a counterpart to 
Darwin, as in Charles.

-Original Message-
From: Discuss-gnustep  On 
Behalf Of Pirmin Braun
Sent: Tuesday, November 26, 2019 6:10 PM
To: Gregory Casamento 
Cc: Discuss-gnustep Discuss 
Subject: Re: Which ObjC2.0 features are missing in the latest GCC?

I'd suggest a fork, i.e. "Gnustep2" with LLVM, Clang, libobjc2 

On Tue, 26 Nov 2019 04:55:43 -0500
Gregory Casamento  wrote:

> I'd really like some resolution on this topic.   There seem to be a lot of
> reasons for and against.
> 
> GC
> 
> On Mon, Nov 25, 2019 at 1:04 PM David Chisnall 
> 
> wrote:
> 
> > On 25 Nov 2019, at 14:07, H. Nikolaus Schaller  wrote:
> > > I am not sure that this is the only way to implement it.
> > >
> > > First of all the callMethodOn returns some block which is a data
> > structure knowing that it should take the parameter x and do some function.
> > > Let's call it NSBlock. NSBlock can be an ordinary object like any 
> > > other
> > so that it can follow the same memory management rules as used otherwise.
> >
> > That’s shifting the goalposts somewhat.  It is not news that objects 
> > and closures are equivalent.  Smalltalk implemented blocks as 
> > BlockClosure objects, Ian Piumarta’s Composite Object-Lambda 
> > Architecture, and C++ lambdas (which are just shorthand for C++ 
> > objects that implement `operator()`).  You can always express 
> > anything that uses blocks with objects.
> >
> > There are two issues:
> >
> > 1. If you want to be compatible with existing APIs that use blocks, 
> > you need to be ABI compatible with blocks.
> > 2. The reason that most languages that have objects also have blocks 
> > is that the shorthand syntax is very convenient.
> >
> > The following are roughly equivalent:
> >
> > ```
> > @interface Delegate : NSObject
> > - (void)invoke;
> > - (instancetype)initWithCapture: (id)someObject; @end
> >
> > @implementation Delegate
> > {
> > @private
> > id obj;
> > }
> > - (instancetype)initWithCapture: (id)someObject {
> > if ((self = [super init]) == nil) return nil;
> > obj = [someObject retain];
> > return self;
> > }
> > - (void)invoke
> > {
> > [obj doSomething];
> > }
> > - (void)dealloc
> > {
> > [obj release];
> > [super dealloc];
> > }
> > @end
> >
> > // At construction site:
> >
> > [[Delegate alloc] initWithCapture: x];
> >
> > // At use site:
> >
> > [delegate invoke];
> > ```
> >
> > And this, with blocks:
> >
> > ```
> > // At construction site:
> >
> > ^() { [x doSomething]; };
> >
> > // At use site:
> >
> > delegate();
> > ```
> >
> > At use, these are similar complexity for the programmer.  At the 
> > point of construction, one is one line of code (two or three if you 
> > put lambda bodies on their own lines), the other is 26.  As a 
> > programmer, I don’t want to write 26 lines of code for a one-line callback.
> >
> > In C++98 you could probably template that and provide a generic 
> > class that took a struct containing the captures and a C function, 
> > so you’d get a lot less boilerplate.  Assuming you had fudged ARC 
> > like this (as above, this code is typed into a mail client and probably 
> > doesn’t compile):
> >
> > ```
> > template
> > struct ObjCObjectWrapper
> > {
> > ObjCObjectWrapper(T x) : obj(objc_retain(x)) {}
> > ObjCObjectWrapper(const ObjCObjectWrapper ) :
> > obj(objc_retain(other.obj) {}
> > ObjCObjectWrapper(ObjCObjectWrapper &) : obj(other.obj)
> > {
> > other.obj = nil;
> > }
> > ObjCObjectWrapper()
> > {
> > objc_release(obj);
> > }
> > operator=(T x)
> > {
> > objc_storeStrong(, x);
> > }
> > T operator()
> > {
> > return obj;
> > }
> > private:
> > T obj;
> >
> > };
> > ```
> >
> > You could then define a generic capture structure and invoke method 
> > like

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 26 Nov 2019, at 15:06, H. Nikolaus Schaller  wrote:
> 
> 
>> Am 26.11.2019 um 11:09 schrieb Pirmin Braun :
>> 
>> I'd suggest a fork, i.e. "Gnustep2" with LLVM, Clang, libobjc2 
> 
> just came to my mind: ClangSTEP?


what a tong breaker. FreeStep sounds better to me :)
Drop the "GNU" and break free.


> 
>> 
>> On Tue, 26 Nov 2019 04:55:43 -0500
>> Gregory Casamento  wrote:
>> 
>>> I'd really like some resolution on this topic.   There seem to be a lot of
>>> reasons for and against.
>>> 
>>> GC
>>> 
>>> On Mon, Nov 25, 2019 at 1:04 PM David Chisnall 
>>> wrote:
>>> 
 On 25 Nov 2019, at 14:07, H. Nikolaus Schaller  wrote:
> I am not sure that this is the only way to implement it.
> 
> First of all the callMethodOn returns some block which is a data
 structure knowing that it should take the parameter x and do some function.
> Let's call it NSBlock. NSBlock can be an ordinary object like any other
 so that it can follow the same memory management rules as used otherwise.
 
 That’s shifting the goalposts somewhat.  It is not news that objects and
 closures are equivalent.  Smalltalk implemented blocks as BlockClosure
 objects, Ian Piumarta’s Composite Object-Lambda Architecture, and C++
 lambdas (which are just shorthand for C++ objects that implement
 `operator()`).  You can always express anything that uses blocks with
 objects.
 
 There are two issues:
 
 1. If you want to be compatible with existing APIs that use blocks, you
 need to be ABI compatible with blocks.
 2. The reason that most languages that have objects also have blocks is
 that the shorthand syntax is very convenient.
 
 The following are roughly equivalent:
 
 ```
 @interface Delegate : NSObject
 - (void)invoke;
 - (instancetype)initWithCapture: (id)someObject;
 @end
 
 @implementation Delegate
 {
   @private
   id obj;
 }
 - (instancetype)initWithCapture: (id)someObject
 {
   if ((self = [super init]) == nil) return nil;
   obj = [someObject retain];
   return self;
 }
 - (void)invoke
 {
   [obj doSomething];
 }
 - (void)dealloc
 {
   [obj release];
   [super dealloc];
 }
 @end
 
 // At construction site:
 
 [[Delegate alloc] initWithCapture: x];
 
 // At use site:
 
 [delegate invoke];
 ```
 
 And this, with blocks:
 
 ```
 // At construction site:
 
 ^() { [x doSomething]; };
 
 // At use site:
 
 delegate();
 ```
 
 At use, these are similar complexity for the programmer.  At the point of
 construction, one is one line of code (two or three if you put lambda
 bodies on their own lines), the other is 26.  As a programmer, I don’t want
 to write 26 lines of code for a one-line callback.
 
 In C++98 you could probably template that and provide a generic class that
 took a struct containing the captures and a C function, so you’d get a lot
 less boilerplate.  Assuming you had fudged ARC like this (as above, this
 code is typed into a mail client and probably doesn’t compile):
 
 ```
 template
 struct ObjCObjectWrapper
 {
   ObjCObjectWrapper(T x) : obj(objc_retain(x)) {}
   ObjCObjectWrapper(const ObjCObjectWrapper ) :
 obj(objc_retain(other.obj) {}
   ObjCObjectWrapper(ObjCObjectWrapper &) : obj(other.obj)
   {
   other.obj = nil;
   }
   ObjCObjectWrapper()
   {
   objc_release(obj);
   }
   operator=(T x)
   {
   objc_storeStrong(, x);
   }
   T operator()
   {
   return obj;
   }
   private:
   T obj;
 
 };
 ```
 
 You could then define a generic capture structure and invoke method like
 this:
 
 ```
 template
 struct BlockImpl
 {
   using invoke_t = Ret(*)(Capture &, Args...);
   void operator()(Args... args)
   {
   inv(capture, std::forward(args)…);
   }
   Block(Capture &, invoke_t fn) : capture(c), inv(fn) {}
   private:
   Capture capture;
   invoke_t inv;
 };
 ```
 
 This is then generic and you could use it as follows:
 
 ```
 struct CaptureOneObject
 {
   ObjCObjectWrapper o;
 };
 void invoke(CaptureOneObject )
 {
   [(id)c.o doSomething];
 }
 // At construction site:
 std::function block(BlockImpl({x},
 invoke));
 // At use site:
 block();
 ```
 
 I *think* you could get the same ABI as blocks if you worked on the
 generic templated boilerplate a bit.
 
 Of course, if you were using C++ then you could also write it using

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 26.11.2019 um 11:09 schrieb Pirmin Braun :
> 
> I'd suggest a fork, i.e. "Gnustep2" with LLVM, Clang, libobjc2 

just came to my mind: ClangSTEP?

> 
> On Tue, 26 Nov 2019 04:55:43 -0500
> Gregory Casamento  wrote:
> 
>> I'd really like some resolution on this topic.   There seem to be a lot of
>> reasons for and against.
>> 
>> GC
>> 
>> On Mon, Nov 25, 2019 at 1:04 PM David Chisnall 
>> wrote:
>> 
>>> On 25 Nov 2019, at 14:07, H. Nikolaus Schaller  wrote:
 I am not sure that this is the only way to implement it.
 
 First of all the callMethodOn returns some block which is a data
>>> structure knowing that it should take the parameter x and do some function.
 Let's call it NSBlock. NSBlock can be an ordinary object like any other
>>> so that it can follow the same memory management rules as used otherwise.
>>> 
>>> That’s shifting the goalposts somewhat.  It is not news that objects and
>>> closures are equivalent.  Smalltalk implemented blocks as BlockClosure
>>> objects, Ian Piumarta’s Composite Object-Lambda Architecture, and C++
>>> lambdas (which are just shorthand for C++ objects that implement
>>> `operator()`).  You can always express anything that uses blocks with
>>> objects.
>>> 
>>> There are two issues:
>>> 
>>> 1. If you want to be compatible with existing APIs that use blocks, you
>>> need to be ABI compatible with blocks.
>>> 2. The reason that most languages that have objects also have blocks is
>>> that the shorthand syntax is very convenient.
>>> 
>>> The following are roughly equivalent:
>>> 
>>> ```
>>> @interface Delegate : NSObject
>>> - (void)invoke;
>>> - (instancetype)initWithCapture: (id)someObject;
>>> @end
>>> 
>>> @implementation Delegate
>>> {
>>>@private
>>>id obj;
>>> }
>>> - (instancetype)initWithCapture: (id)someObject
>>> {
>>>if ((self = [super init]) == nil) return nil;
>>>obj = [someObject retain];
>>>return self;
>>> }
>>> - (void)invoke
>>> {
>>>[obj doSomething];
>>> }
>>> - (void)dealloc
>>> {
>>>[obj release];
>>>[super dealloc];
>>> }
>>> @end
>>> 
>>> // At construction site:
>>> 
>>> [[Delegate alloc] initWithCapture: x];
>>> 
>>> // At use site:
>>> 
>>> [delegate invoke];
>>> ```
>>> 
>>> And this, with blocks:
>>> 
>>> ```
>>> // At construction site:
>>> 
>>> ^() { [x doSomething]; };
>>> 
>>> // At use site:
>>> 
>>> delegate();
>>> ```
>>> 
>>> At use, these are similar complexity for the programmer.  At the point of
>>> construction, one is one line of code (two or three if you put lambda
>>> bodies on their own lines), the other is 26.  As a programmer, I don’t want
>>> to write 26 lines of code for a one-line callback.
>>> 
>>> In C++98 you could probably template that and provide a generic class that
>>> took a struct containing the captures and a C function, so you’d get a lot
>>> less boilerplate.  Assuming you had fudged ARC like this (as above, this
>>> code is typed into a mail client and probably doesn’t compile):
>>> 
>>> ```
>>> template
>>> struct ObjCObjectWrapper
>>> {
>>>ObjCObjectWrapper(T x) : obj(objc_retain(x)) {}
>>>ObjCObjectWrapper(const ObjCObjectWrapper ) :
>>> obj(objc_retain(other.obj) {}
>>>ObjCObjectWrapper(ObjCObjectWrapper &) : obj(other.obj)
>>>{
>>>other.obj = nil;
>>>}
>>>ObjCObjectWrapper()
>>>{
>>>objc_release(obj);
>>>}
>>>operator=(T x)
>>>{
>>>objc_storeStrong(, x);
>>>}
>>>T operator()
>>>{
>>>return obj;
>>>}
>>>private:
>>>T obj;
>>> 
>>> };
>>> ```
>>> 
>>> You could then define a generic capture structure and invoke method like
>>> this:
>>> 
>>> ```
>>> template
>>> struct BlockImpl
>>> {
>>>using invoke_t = Ret(*)(Capture &, Args...);
>>>void operator()(Args... args)
>>>{
>>>inv(capture, std::forward(args)…);
>>>}
>>>Block(Capture &, invoke_t fn) : capture(c), inv(fn) {}
>>>private:
>>>Capture capture;
>>>invoke_t inv;
>>> };
>>> ```
>>> 
>>> This is then generic and you could use it as follows:
>>> 
>>> ```
>>> struct CaptureOneObject
>>> {
>>>ObjCObjectWrapper o;
>>> };
>>> void invoke(CaptureOneObject )
>>> {
>>>[(id)c.o doSomething];
>>> }
>>> // At construction site:
>>> std::function block(BlockImpl({x},
>>> invoke));
>>> // At use site:
>>> block();
>>> ```
>>> 
>>> I *think* you could get the same ABI as blocks if you worked on the
>>> generic templated boilerplate a bit.
>>> 
>>> Of course, if you were using C++ then you could also write it using
>>> lambdas as:
>>> 
>>> ```
>>> // At construction site
>>> ObjCObjectWrapper capture(x);
>>> auto block = [=capture]() { [(id)capture.o doSomething]; };
>>> // At use site:
>>> block();
>>> ```
>>> 
>>> And with this you don’t need the invoke function or the capture class.
>>> Again, 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Pirmin Braun]

I'd suggest a fork, i.e. "Gnustep2" with LLVM, Clang, libobjc2 

On Tue, 26 Nov 2019 04:55:43 -0500
Gregory Casamento  wrote:

> I'd really like some resolution on this topic.   There seem to be a lot of
> reasons for and against.
> 
> GC
> 
> On Mon, Nov 25, 2019 at 1:04 PM David Chisnall 
> wrote:
> 
> > On 25 Nov 2019, at 14:07, H. Nikolaus Schaller  wrote:
> > > I am not sure that this is the only way to implement it.
> > >
> > > First of all the callMethodOn returns some block which is a data
> > structure knowing that it should take the parameter x and do some function.
> > > Let's call it NSBlock. NSBlock can be an ordinary object like any other
> > so that it can follow the same memory management rules as used otherwise.
> >
> > That’s shifting the goalposts somewhat.  It is not news that objects and
> > closures are equivalent.  Smalltalk implemented blocks as BlockClosure
> > objects, Ian Piumarta’s Composite Object-Lambda Architecture, and C++
> > lambdas (which are just shorthand for C++ objects that implement
> > `operator()`).  You can always express anything that uses blocks with
> > objects.
> >
> > There are two issues:
> >
> > 1. If you want to be compatible with existing APIs that use blocks, you
> > need to be ABI compatible with blocks.
> > 2. The reason that most languages that have objects also have blocks is
> > that the shorthand syntax is very convenient.
> >
> > The following are roughly equivalent:
> >
> > ```
> > @interface Delegate : NSObject
> > - (void)invoke;
> > - (instancetype)initWithCapture: (id)someObject;
> > @end
> >
> > @implementation Delegate
> > {
> > @private
> > id obj;
> > }
> > - (instancetype)initWithCapture: (id)someObject
> > {
> > if ((self = [super init]) == nil) return nil;
> > obj = [someObject retain];
> > return self;
> > }
> > - (void)invoke
> > {
> > [obj doSomething];
> > }
> > - (void)dealloc
> > {
> > [obj release];
> > [super dealloc];
> > }
> > @end
> >
> > // At construction site:
> >
> > [[Delegate alloc] initWithCapture: x];
> >
> > // At use site:
> >
> > [delegate invoke];
> > ```
> >
> > And this, with blocks:
> >
> > ```
> > // At construction site:
> >
> > ^() { [x doSomething]; };
> >
> > // At use site:
> >
> > delegate();
> > ```
> >
> > At use, these are similar complexity for the programmer.  At the point of
> > construction, one is one line of code (two or three if you put lambda
> > bodies on their own lines), the other is 26.  As a programmer, I don’t want
> > to write 26 lines of code for a one-line callback.
> >
> > In C++98 you could probably template that and provide a generic class that
> > took a struct containing the captures and a C function, so you’d get a lot
> > less boilerplate.  Assuming you had fudged ARC like this (as above, this
> > code is typed into a mail client and probably doesn’t compile):
> >
> > ```
> > template
> > struct ObjCObjectWrapper
> > {
> > ObjCObjectWrapper(T x) : obj(objc_retain(x)) {}
> > ObjCObjectWrapper(const ObjCObjectWrapper ) :
> > obj(objc_retain(other.obj) {}
> > ObjCObjectWrapper(ObjCObjectWrapper &) : obj(other.obj)
> > {
> > other.obj = nil;
> > }
> > ObjCObjectWrapper()
> > {
> > objc_release(obj);
> > }
> > operator=(T x)
> > {
> > objc_storeStrong(, x);
> > }
> > T operator()
> > {
> > return obj;
> > }
> > private:
> > T obj;
> >
> > };
> > ```
> >
> > You could then define a generic capture structure and invoke method like
> > this:
> >
> > ```
> > template
> > struct BlockImpl
> > {
> > using invoke_t = Ret(*)(Capture &, Args...);
> > void operator()(Args... args)
> > {
> > inv(capture, std::forward(args)…);
> > }
> > Block(Capture &, invoke_t fn) : capture(c), inv(fn) {}
> > private:
> > Capture capture;
> > invoke_t inv;
> > };
> > ```
> >
> > This is then generic and you could use it as follows:
> >
> > ```
> > struct CaptureOneObject
> > {
> > ObjCObjectWrapper o;
> > };
> > void invoke(CaptureOneObject )
> > {
> > [(id)c.o doSomething];
> > }
> > // At construction site:
> > std::function block(BlockImpl({x},
> > invoke));
> > // At use site:
> > block();
> > ```
> >
> > I *think* you could get the same ABI as blocks if you worked on the
> > generic templated boilerplate a bit.
> >
> > Of course, if you were using C++ then you could also write it using
> > lambdas as:
> >
> > ```
> > // At construction site
> > ObjCObjectWrapper capture(x);
> > auto block = [=capture]() { [(id)capture.o doSomething]; };
> > // At use site:
> > block();
> > ```
> >
> > And with this you don’t need the invoke function or the capture class.
> > Again, much less boiler plate for users, though we don’t have ABI
> > compatibility with blocks.
> >

Re: Which ObjC2.0 features are missing in the latest GCC?

[Max Chan]

How’s the poll going?

顺颂商祺
陈北宗 Max Chan, from SushiBits Projects
Tel. +86 186-2165-8748
https://github.com/SushiBits

> On Nov 26, 2019, at 17:55, Gregory Casamento  wrote:
> 
> 
> 
> I'd really like some resolution on this topic.   There seem to be a lot of 
> reasons for and against.
> 
> GC
> 
> 
>> On Mon, Nov 25, 2019 at 1:04 PM David Chisnall  
>> wrote:
>> On 25 Nov 2019, at 14:07, H. Nikolaus Schaller  wrote:
>> > I am not sure that this is the only way to implement it.
>> > 
>> > First of all the callMethodOn returns some block which is a data structure 
>> > knowing that it should take the parameter x and do some function.
>> > Let's call it NSBlock. NSBlock can be an ordinary object like any other so 
>> > that it can follow the same memory management rules as used otherwise.
>> 
>> That’s shifting the goalposts somewhat.  It is not news that objects and 
>> closures are equivalent.  Smalltalk implemented blocks as BlockClosure 
>> objects, Ian Piumarta’s Composite Object-Lambda Architecture, and C++ 
>> lambdas (which are just shorthand for C++ objects that implement 
>> `operator()`).  You can always express anything that uses blocks with 
>> objects.
>> 
>> There are two issues:
>> 
>> 1. If you want to be compatible with existing APIs that use blocks, you need 
>> to be ABI compatible with blocks.
>> 2. The reason that most languages that have objects also have blocks is that 
>> the shorthand syntax is very convenient.
>> 
>> The following are roughly equivalent:
>> 
>> ```
>> @interface Delegate : NSObject
>> - (void)invoke;
>> - (instancetype)initWithCapture: (id)someObject;
>> @end
>> 
>> @implementation Delegate
>> {
>> @private
>> id obj;
>> }
>> - (instancetype)initWithCapture: (id)someObject
>> {
>> if ((self = [super init]) == nil) return nil;
>> obj = [someObject retain];
>> return self;
>> }
>> - (void)invoke
>> {
>> [obj doSomething];
>> }
>> - (void)dealloc
>> {
>> [obj release];
>> [super dealloc];
>> }
>> @end
>> 
>> // At construction site:
>> 
>> [[Delegate alloc] initWithCapture: x];
>> 
>> // At use site:
>> 
>> [delegate invoke];
>> ```
>> 
>> And this, with blocks:
>> 
>> ```
>> // At construction site:
>> 
>> ^() { [x doSomething]; };
>> 
>> // At use site:
>> 
>> delegate();
>> ```
>> 
>> At use, these are similar complexity for the programmer.  At the point of 
>> construction, one is one line of code (two or three if you put lambda bodies 
>> on their own lines), the other is 26.  As a programmer, I don’t want to 
>> write 26 lines of code for a one-line callback.
>> 
>> In C++98 you could probably template that and provide a generic class that 
>> took a struct containing the captures and a C function, so you’d get a lot 
>> less boilerplate.  Assuming you had fudged ARC like this (as above, this 
>> code is typed into a mail client and probably doesn’t compile):
>> 
>> ```
>> template
>> struct ObjCObjectWrapper
>> {
>> ObjCObjectWrapper(T x) : obj(objc_retain(x)) {}
>> ObjCObjectWrapper(const ObjCObjectWrapper ) : 
>> obj(objc_retain(other.obj) {}
>> ObjCObjectWrapper(ObjCObjectWrapper &) : obj(other.obj)
>> {
>> other.obj = nil;
>> }
>> ObjCObjectWrapper()
>> {
>> objc_release(obj);
>> }
>> operator=(T x)
>> {
>> objc_storeStrong(, x);
>> }
>> T operator()
>> {
>> return obj;
>> }
>> private:
>> T obj;
>> 
>> };
>> ```
>> 
>> You could then define a generic capture structure and invoke method like 
>> this:
>> 
>> ```
>> template
>> struct BlockImpl
>> {
>> using invoke_t = Ret(*)(Capture &, Args...);
>> void operator()(Args... args)
>> {
>> inv(capture, std::forward(args)…);
>> }
>> Block(Capture &, invoke_t fn) : capture(c), inv(fn) {}
>> private:
>> Capture capture;
>> invoke_t inv;
>> };
>> ```
>> 
>> This is then generic and you could use it as follows:
>> 
>> ```
>> struct CaptureOneObject
>> {
>> ObjCObjectWrapper o;
>> };
>> void invoke(CaptureOneObject )
>> {
>> [(id)c.o doSomething];
>> }
>> // At construction site:
>> std::function block(BlockImpl({x}, 
>> invoke));
>> // At use site:
>> block();
>> ```
>> 
>> I *think* you could get the same ABI as blocks if you worked on the generic 
>> templated boilerplate a bit.
>> 
>> Of course, if you were using C++ then you could also write it using lambdas 
>> as:
>> 
>> ```
>> // At construction site
>> ObjCObjectWrapper capture(x);
>> auto block = [=capture]() { [(id)capture.o doSomething]; };
>> // At use site:
>> block();
>> ```
>> 
>> And with this you don’t need the invoke function or the capture class.  
>> Again, much less boiler plate for users, though we don’t have ABI 
>> compatibility with blocks.  
>> 
>> If you were using ARC and C++, then this 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Gregory Casamento]

I'd really like some resolution on this topic.   There seem to be a lot of
reasons for and against.

GC

On Mon, Nov 25, 2019 at 1:04 PM David Chisnall 
wrote:

> On 25 Nov 2019, at 14:07, H. Nikolaus Schaller  wrote:
> > I am not sure that this is the only way to implement it.
> >
> > First of all the callMethodOn returns some block which is a data
> structure knowing that it should take the parameter x and do some function.
> > Let's call it NSBlock. NSBlock can be an ordinary object like any other
> so that it can follow the same memory management rules as used otherwise.
>
> That’s shifting the goalposts somewhat.  It is not news that objects and
> closures are equivalent.  Smalltalk implemented blocks as BlockClosure
> objects, Ian Piumarta’s Composite Object-Lambda Architecture, and C++
> lambdas (which are just shorthand for C++ objects that implement
> `operator()`).  You can always express anything that uses blocks with
> objects.
>
> There are two issues:
>
> 1. If you want to be compatible with existing APIs that use blocks, you
> need to be ABI compatible with blocks.
> 2. The reason that most languages that have objects also have blocks is
> that the shorthand syntax is very convenient.
>
> The following are roughly equivalent:
>
> ```
> @interface Delegate : NSObject
> - (void)invoke;
> - (instancetype)initWithCapture: (id)someObject;
> @end
>
> @implementation Delegate
> {
> @private
> id obj;
> }
> - (instancetype)initWithCapture: (id)someObject
> {
> if ((self = [super init]) == nil) return nil;
> obj = [someObject retain];
> return self;
> }
> - (void)invoke
> {
> [obj doSomething];
> }
> - (void)dealloc
> {
> [obj release];
> [super dealloc];
> }
> @end
>
> // At construction site:
>
> [[Delegate alloc] initWithCapture: x];
>
> // At use site:
>
> [delegate invoke];
> ```
>
> And this, with blocks:
>
> ```
> // At construction site:
>
> ^() { [x doSomething]; };
>
> // At use site:
>
> delegate();
> ```
>
> At use, these are similar complexity for the programmer.  At the point of
> construction, one is one line of code (two or three if you put lambda
> bodies on their own lines), the other is 26.  As a programmer, I don’t want
> to write 26 lines of code for a one-line callback.
>
> In C++98 you could probably template that and provide a generic class that
> took a struct containing the captures and a C function, so you’d get a lot
> less boilerplate.  Assuming you had fudged ARC like this (as above, this
> code is typed into a mail client and probably doesn’t compile):
>
> ```
> template
> struct ObjCObjectWrapper
> {
> ObjCObjectWrapper(T x) : obj(objc_retain(x)) {}
> ObjCObjectWrapper(const ObjCObjectWrapper ) :
> obj(objc_retain(other.obj) {}
> ObjCObjectWrapper(ObjCObjectWrapper &) : obj(other.obj)
> {
> other.obj = nil;
> }
> ObjCObjectWrapper()
> {
> objc_release(obj);
> }
> operator=(T x)
> {
> objc_storeStrong(, x);
> }
> T operator()
> {
> return obj;
> }
> private:
> T obj;
>
> };
> ```
>
> You could then define a generic capture structure and invoke method like
> this:
>
> ```
> template
> struct BlockImpl
> {
> using invoke_t = Ret(*)(Capture &, Args...);
> void operator()(Args... args)
> {
> inv(capture, std::forward(args)…);
> }
> Block(Capture &, invoke_t fn) : capture(c), inv(fn) {}
> private:
> Capture capture;
> invoke_t inv;
> };
> ```
>
> This is then generic and you could use it as follows:
>
> ```
> struct CaptureOneObject
> {
> ObjCObjectWrapper o;
> };
> void invoke(CaptureOneObject )
> {
> [(id)c.o doSomething];
> }
> // At construction site:
> std::function block(BlockImpl({x},
> invoke));
> // At use site:
> block();
> ```
>
> I *think* you could get the same ABI as blocks if you worked on the
> generic templated boilerplate a bit.
>
> Of course, if you were using C++ then you could also write it using
> lambdas as:
>
> ```
> // At construction site
> ObjCObjectWrapper capture(x);
> auto block = [=capture]() { [(id)capture.o doSomething]; };
> // At use site:
> block();
> ```
>
> And with this you don’t need the invoke function or the capture class.
> Again, much less boiler plate for users, though we don’t have ABI
> compatibility with blocks.
>
> If you were using ARC and C++, then this reduces even further to:
>
> ```
> auto block = [=]() { [x doSomething]; };
> ```
>
> And now we’re back with different syntax for the same thing, though with a
> different ABI (I think Clang has support for implicitly converting C++
> lambdas to blocks, but it’s been a few years since I tried)
>
> David
>
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - 

Re: Which ObjC2.0 features are missing in the latest GCC?

[David Chisnall]

On 25 Nov 2019, at 14:07, H. Nikolaus Schaller  wrote:
> I am not sure that this is the only way to implement it.
> 
> First of all the callMethodOn returns some block which is a data structure 
> knowing that it should take the parameter x and do some function.
> Let's call it NSBlock. NSBlock can be an ordinary object like any other so 
> that it can follow the same memory management rules as used otherwise.

That’s shifting the goalposts somewhat.  It is not news that objects and 
closures are equivalent.  Smalltalk implemented blocks as BlockClosure objects, 
Ian Piumarta’s Composite Object-Lambda Architecture, and C++ lambdas (which are 
just shorthand for C++ objects that implement `operator()`).  You can always 
express anything that uses blocks with objects.

There are two issues:

1. If you want to be compatible with existing APIs that use blocks, you need to 
be ABI compatible with blocks.
2. The reason that most languages that have objects also have blocks is that 
the shorthand syntax is very convenient.

The following are roughly equivalent:

```
@interface Delegate : NSObject
- (void)invoke;
- (instancetype)initWithCapture: (id)someObject;
@end

@implementation Delegate
{
@private
id obj;
}
- (instancetype)initWithCapture: (id)someObject
{
if ((self = [super init]) == nil) return nil;
obj = [someObject retain];
return self;
}
- (void)invoke
{
[obj doSomething];
}
- (void)dealloc
{
[obj release];
[super dealloc];
}
@end

// At construction site:

[[Delegate alloc] initWithCapture: x];

// At use site:

[delegate invoke];
```

And this, with blocks:

```
// At construction site:

^() { [x doSomething]; };

// At use site:

delegate();
```

At use, these are similar complexity for the programmer.  At the point of 
construction, one is one line of code (two or three if you put lambda bodies on 
their own lines), the other is 26.  As a programmer, I don’t want to write 26 
lines of code for a one-line callback.

In C++98 you could probably template that and provide a generic class that took 
a struct containing the captures and a C function, so you’d get a lot less 
boilerplate.  Assuming you had fudged ARC like this (as above, this code is 
typed into a mail client and probably doesn’t compile):

```
template
struct ObjCObjectWrapper
{
ObjCObjectWrapper(T x) : obj(objc_retain(x)) {}
ObjCObjectWrapper(const ObjCObjectWrapper ) : 
obj(objc_retain(other.obj) {}
ObjCObjectWrapper(ObjCObjectWrapper &) : obj(other.obj)
{
other.obj = nil;
}
ObjCObjectWrapper()
{
objc_release(obj);
}
operator=(T x)
{
objc_storeStrong(, x);
}
T operator()
{
return obj;
}
private:
T obj;

};
```

You could then define a generic capture structure and invoke method like this:

```
template
struct BlockImpl
{
using invoke_t = Ret(*)(Capture &, Args...);
void operator()(Args... args)
{
inv(capture, std::forward(args)…);
}
Block(Capture &, invoke_t fn) : capture(c), inv(fn) {}
private:
Capture capture;
invoke_t inv;
};
```

This is then generic and you could use it as follows:

```
struct CaptureOneObject
{
ObjCObjectWrapper o;
};
void invoke(CaptureOneObject )
{
[(id)c.o doSomething];
}
// At construction site:
std::function block(BlockImpl({x}, invoke));
// At use site:
block();
```

I *think* you could get the same ABI as blocks if you worked on the generic 
templated boilerplate a bit.

Of course, if you were using C++ then you could also write it using lambdas as:

```
// At construction site
ObjCObjectWrapper capture(x);
auto block = [=capture]() { [(id)capture.o doSomething]; };
// At use site:
block();
```

And with this you don’t need the invoke function or the capture class.  Again, 
much less boiler plate for users, though we don’t have ABI compatibility with 
blocks.  

If you were using ARC and C++, then this reduces even further to:

```
auto block = [=]() { [x doSomething]; };
```

And now we’re back with different syntax for the same thing, though with a 
different ABI (I think Clang has support for implicitly converting C++ lambdas 
to blocks, but it’s been a few years since I tried)

David

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 25.11.2019 um 18:40 schrieb Fred Kiefer :
> 
> 
> 
>> Am 25.11.2019 um 11:18 schrieb H. Nikolaus Schaller :
>> 
>> Fred mentioned that it could be possible to define some block wrapper macros 
>> if some time is invested.
>> It that works out, we do not make our decisions depend on gcc *not* 
>> implementing something.
> 
> 
> I may not have been clear enough on that point. I think that limited block 
> support might be possible even with gcc, a full implementation is probably 
> out of reach.

The question is what we need. Maybe not some exotic corner cases.
IMHO, they are mainly used as callbacks from asynchronous activities 
(networking).

In ObjC1 this was handled by delegates or blocking and passing back complete 
results instead of callbacks.

It looks like the key aspect is to get new block based method names in header 
files (almost) compatible.
Well, we never can automatically replace ^ by something in application code by 
a cpp macro.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Ivan Vučica]

Look, I'm saying these things as someone that wants free software to
succeed, and I wish I could write more of it.

I also want GCC to be usable in the core.

However, not using a better runtime than GCC's and not using an
ARC-enabled compiler has costs for free software.

On Sun, Nov 24, 2019 at 1:24 AM Yavor Doganov  wrote:
>
> Developers who want to start using these new (not so new -- 10 years
> old!) features have the option to build the environment they need on
> top of Debian (if that is their distro of choice) or switch to another
> distro that provides prebuilt packages.

Debian and Ubuntu and derivatives are distros of choice for a large
number of users, incl. developers. Developers go ahead and just apt
install the libraries. Aside from UI concerns, they may or may not be
surprised to see a lack of language features they are used to on Mac,
used in sample code etc.

> You, developers, tend to forget that free software is for users.
> Developers are users too in a broad sense but they are a very small
> part of the whole mass of people using a particular piece of software.
> If these fancy features existed for 10 years, why they have not
> inclined developers to write more free software that is relying on
> them?  Surely that's not because Debian stopped them?  Or because the
> GNUstep project is stopping them?

Honestly, the things I lack to write an app:

1. various APIs
2. good autocomplete
3. better interface builder

All fixable in GNUstep without touching the compiler, and either way,
for me, all ignorable.

Now, let's say I start writing a fancy new app conforming to
best-practices way for people still using Objective-C with Cocoa.
Perhaps I'm starting on Debian with intention to support the package
to be built for Debian, and using lowest-common-denominator when it
comes to APIs.

I discover that even the lowest-common-denominator API-wise means I
have to avoid a bunch of language features.

Yknow what I do then? I don't necessarily go and build from source, I
drop the platform.

> My task as a free software contributor (with the extremely limited
> skills I have) is to help achieve the goals of the Free Software
> Movement.  Providing "tons and tons of features" to developers who
> don't care at all about free software (at least the majority of them)
> and who won't write a single line of code for the cause I'm aligned to
> doesn't strike me as the "right" thing to do.

I think you're conflating 'people who want to use new language
features' with 'people who develop proprietary software'.

I assure you that people who want to develop proprietary software
using GNUstep on Debian are well capable of doing that, including
using new features -- and they don't need to use prepackaged binaries
:)

People who want to discover GNUstep using Debian and want to use new
language features in free software might drop it instead of figuring
out how to build it from source. I mean, when I started off, I just
wanted to port my (never finished) free-software outliner (a tool to
edit OPML files). I was not interested in learning how to build
GNUstep or studying how the core works. I worked around
NSWindowController (or was it NSViewController?) missing in GNUstep,
and after complaining on the mailing list, I was told it was already
in the core, and I didn't have it because Debian packages were out of
date.

It took me quite a bit of time to bite the bullet and try to build
things -- because I trust Debian and want to, systemwide, install
minimum amount of non-packaged software that I can. Also, targeting
Debian was important to me, and writing something that was
unpackagable was something I didn't want to do. I never got any of my
own software into packagable state, though I was sometimes close.

> I don't mind helping them as a side effect of helping free software.
> In this case, however, it is all about them.

No, I don't think switching compilers to enable ARC for new developers
is helping only proprietary software :-)

>
> > - ARC is one.
> > - Blocks is another.
> > - @123 syntax for NSNumber (and similar stuff for arrays and dicts and
> > more) is another.
> > - Improved @property support is yet another.
>
> This is like offering rocket fuel to someone who has a car with a
> diesel engine.  None of the packages in Debian is using these
> features, which is why I said there's nothing to win.  There's a queue
> of software packages we intend to package in Debian but neither of
> them depends on these things -- except probably the Rik theme and
> NEXTSPACE (which are not suitable for packaging for other reasons).

Catch 22. You're describing a catch 22.

Even if I wanted to use ARC, I would choose not to, because I want it
to be usable with Debian. And you're telling me that libobjc2 and
clang are a no go.

But I am actually the weird one here: new Objective-C developers --
and I don't know if we'll get more of them in the free software world
given how Objective-C is treated on the proprietary 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Matt Butch]

> On Nov 25, 2019, at 12:07, Andreas Fink  wrote:
> 
>> On 25 Nov 2019, at 14:37, Yavor Doganov > > wrote:
>> 
>> Gregory Casamento wrote:
>>> On Fri, Nov 22, 2019 at 3:01 PM Yavor Doganov >> > wrote:
 The answer is simple: because there's a lot to lose and nothing to
 gain.
>> 
>>> This is patently incorrect.  The gain is time and compatibility with
>>> the latest code base.  I laid out the advantages and disadvantages
>>> of this in my previous posting.
>> 
>> There are no advantages for the current GNUstep packages in Debian
>> which is the main point I was trying to make.  I don't dispute the
>> fact that dropping support for GCC will simplify things a lot for
>> you.  At certain cost, of course, which you consider negligible.
>> 
>>> * More Applications, more applications means more end users (sort of
>>> chicken and egg thing)
>> 
>> That's purely hypothetical to the extent of being mere speculation.
>> GNUstep supports Clang and David's runtime for quite some time now,
>> why there are no more applications?  Why existing GNUstep applications
>> have not been updated to take advantage of the new features?
> 
> I can tell you exactly why. When I tried out GNUstep for the first time to 
> port my OS X apps to Debian, I simply did "apt-get install gnustep" and 
> wanted to compile my code and nothing really worked.
> Then it took me several weeks to figure out how to get a working toolchain 
> with libobjc2 and ARC support which my code required. And I am not a newbie. 
> I write code on MacOS since 1994 and Linux since like 1992. The major 
> roadblocks where:
> 
> a) the tools which come with Debian where totally useless as it did not 
> support modern Objc2 features which my ported code was using already. And it 
> took a while to even figure that out.
> b) the build process is not well documented. You find all kinds of build info 
> out there in the net out of which most are totally outdated and don't work 
> anymore. (this has become a bit better since).
> c)  there where some bugs, especially in the linking part which where totally 
> throwing you off the rails and where giving very puzzling information.
> d) if you don't pay attention, the old runtime libobjc which comes with gcc 
> gets into your way. And the package is named libobjc4. So go figure that 
> libobjc2 is actually newer...
> 
> I can assure you that people who are used to MacOS X and Xcode , 99% of it 
> will run away. They will simply claim GnuStep is not a mature project.

I absolutely agree. Either gnustep in the repo should be up to date with clang, 
or there should be a PPA. I understand the later is a pain, but the question is 
not how hard is it but is it worth it to get a better adoption. When I 
discovered GNUstep to utilize Objective-C on non-Mac platforms I was shocked at 
how hard it was to set up right. The Ubuntu package was old and didn’t support 
Objective-C 2.0. And trying to get it working on Objective-C was a pain. I 
updated the script on the Wiki and there was a bunch of steps. Honestly while I 
follow along with the project, I don’t do much with it because its so hard to 
install.

-Matt 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Fred Kiefer]

> Am 25.11.2019 um 11:18 schrieb H. Nikolaus Schaller :
> 
> Fred mentioned that it could be possible to define some block wrapper macros 
> if some time is invested.
> It that works out, we do not make our decisions depend on gcc *not* 
> implementing something.


I may not have been clear enough on that point. I think that limited block 
support might be possible even with gcc, a full implementation is probably out 
of reach.

Re: Which ObjC2.0 features are missing in the latest GCC?

[David Chisnall]

On 25 Nov 2019, at 17:07, Andreas Fink  wrote:
> (https://en.wikipedia.org/wiki/Debian#Architecture_ports)
> 
> As of the Stretch release, the official ports are:[157]

[ snip ]

>   • s390x: z/Architecture with 64-bit userland, intended to replace 
> s390[160]
> Lets see what clang-10 supports under Debian10

[ snip ] 

> # llc-10 --version

[ snip ]

> systemz- SystemZ

[ snip ]

> So the real question is: Are we ok to drop support for s390x  in exchange of 
> support of Objc2.0 support and much cleaner code in libobjc2 ?

FYI: systemz and s390x both refer to IBM’s Z-series mainframes.  IBM has put a 
lot of effort into supporting LLVM on these.  That said, the architecture is 
weird and I suspect that GNUstep (and possibly Clang’s Objective-C support in 
general) would not work.  I’m happy to help anyone who wants to contribute 
Z-series support to Clang’s Objective-C front end and libobjc2 though.  

David

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 25 Nov 2019, at 14:37, Yavor Doganov  wrote:
> 
> Gregory Casamento wrote:
>> On Fri, Nov 22, 2019 at 3:01 PM Yavor Doganov  wrote:
>>> The answer is simple: because there's a lot to lose and nothing to
>>> gain.
> 
>> This is patently incorrect.  The gain is time and compatibility with
>> the latest code base.  I laid out the advantages and disadvantages
>> of this in my previous posting.
> 
> There are no advantages for the current GNUstep packages in Debian
> which is the main point I was trying to make.  I don't dispute the
> fact that dropping support for GCC will simplify things a lot for
> you.  At certain cost, of course, which you consider negligible.
> 
>> * More Applications, more applications means more end users (sort of
>> chicken and egg thing)
> 
> That's purely hypothetical to the extent of being mere speculation.
> GNUstep supports Clang and David's runtime for quite some time now,
> why there are no more applications?  Why existing GNUstep applications
> have not been updated to take advantage of the new features?

I can tell you exactly why. When I tried out GNUstep for the first time to port 
my OS X apps to Debian, I simply did "apt-get install gnustep" and wanted to 
compile my code and nothing really worked.
Then it took me several weeks to figure out how to get a working toolchain with 
libobjc2 and ARC support which my code required. And I am not a newbie. I write 
code on MacOS since 1994 and Linux since like 1992. The major roadblocks where:

a) the tools which come with Debian where totally useless as it did not support 
modern Objc2 features which my ported code was using already. And it took a 
while to even figure that out.
b) the build process is not well documented. You find all kinds of build info 
out there in the net out of which most are totally outdated and don't work 
anymore. (this has become a bit better since).
c)  there where some bugs, especially in the linking part which where totally 
throwing you off the rails and where giving very puzzling information.
d) if you don't pay attention, the old runtime libobjc which comes with gcc 
gets into your way. And the package is named libobjc4. So go figure that 
libobjc2 is actually newer...

I can assure you that people who are used to MacOS X and Xcode , 99% of it will 
run away. They will simply claim GnuStep is not a mature project.

If you read through my readme   
https://github.com/andreasfink/ulib/blob/master/doc/README-Debian9-stretch.txt 

 you will see how many things can go wrong.

Part of the problem was that Debian 9 was packaging clang 3.8 which is quire  
old these days and was lacking some stuff as well.
Recent Debian 10 however fixed this and adding clang from the llvm repository 
to get a newer version is kind of not a big issue. These days you need clang8 
or newer if you don't want to run into some nasty bugs and use a prebuilt 
package.

The linker was one of the biggest problem. Easy to fix but very difficult to 
figure.

I also tried other options beforehand. Namely Cocotron. The problem with that 
was that its built for crosscompiling from a Mac. Recent upgrades from Xcode 
basically broke that and I think the folks who work on that are mainly focused 
to get it run well on Windows and don't care so much about Linux. Also there's 
not much happening with Cocotron these days. Hence I dropped using it and use 
GNUStep for all my ObjC code under Linux these days. And for me its performing 
very well, once I had working packages.



>> What's to lose:
>> * Possibly a political issue with the FSF, but there are other projects
>> which depend on languages not implemented by GCC.
> 
> I'm not aware of any GNU package written in a compiled language that
> cannot be built with GCC.

I'm not aware of any other GNU package written in ObjC (or even any other 
compiled language besides C or C++).


> I don't know what you mean by "political issue" but such a drastic
> change should be discussed with the GNU Project of which GNUstep is
> still part of.  It is wrong to decide it with a vote that doesn't even
> specify simple things like who is eligible to vote and based on what
> majority the decision is going to be taken.  As a GNU maintainer you
> should know these things.
> 
>> * Support for older platforms which ONLY support gcc.
> 
> RISC-V is the newest GNU/Linux architecture and it's not yet supported
> by Clang.

Wrong

https://riscv.org/2019/10/llvm-clang-risc-v-now-supports-lto-michael-larabel-phoronix/
 



> 
>> So, I apologize if I don't agree with the "nothing to gain" opinion.
> 
> You are free to disagree.  But as it often happens with real life, the
> loss may become obvious only post factum...  You could be left only
> with the "gain" which may not look like a big gain then.  It could
> even look more like you have shot 

Re: Which ObjC2.0 features are missing in the latest GCC?

[David Chisnall]

On 25 Nov 2019, at 15:08, Yavor Doganov  wrote:
> 
> David Chisnall wrote:
>> On 25 Nov 2019, at 13:37, Yavor Doganov  wrote:
>>> RISC-V is the newest GNU/Linux architecture and it's not yet
>>> supported by Clang.
>> 
>> Yavor, I appreciate that this is an emotional topic for you, but
>> please can you try to confine yourself to the truth?
> 
> The truth is that none of the llvm-toolchain-* packages ever built on
> Debian's ricv64 autobuilders.  Not even once.  Which means that if we
> are going to build GNUstep with Clang in Debian, it won't be available
> on riscv64.
> 
> This is likely to be fixed in the near future but I'm talking about
> the reality now.

The truth is that RISC-V is a supported architecture for LLVM and is capable of 
self hosting.

If Debian is unable to build the LLVM packages (which, on Debian, are built 
with GCC) then that says a lot more about Debian and GCC than it does about 
LLVM.  Saying that Debian is unable to build LLVM packages on RISC-V is very 
different from saying that RISC-V is not supported by LLVM and intentionally 
conflating the two is misleading.

Since I started writing this, I have read the next mail from you in this thread 
and I would strongly suggest that you take a little break from the computer and 
come back when you can manage to engage in the discussion without being 
offensive.

David

Re: Which ObjC2.0 features are missing in the latest GCC?

[Johannes Brakensiek]

Am 25.11.2019 um 16:31 schrieb Yavor Doganov :
> 
> Johannes Brakensiek wrote:
>>> On 25 Nov 2019, at 14:34, Yavor Doganov wrote:
>>> Off the top of my head, Rik theme is about the single piece of
>>> software that can't be built on stock Debian because of us
>>> sticking to GCC.
>> 
>> thank you for making clear your point. I understood GNUstep would
>> have to provide an updated runtime for all supported architectures
>> and upstream software/applications that rely on clang and its
>> features to make the Debian maintainers distribute it.
> 
> No, that was not my point and nowhere near to what I said.  Debian
> will consider moving to Clang and the new runtime when:
> 
> 1. The pool of new software is large and worthy enough to justify the
>   major regression that is dropping support for about half of the
>   architectures.  It means there has to be much more than Rik that we
>   can't build and package now.  And it appears Rik is buildable with
>   GCC, albeit a less capable version.  So it's not even a proper
>   example.
> 
> 2. The release team approves building an entire software stack with a
>   non-default compiler and as a direct consequence dropping
>   architecure support.
> 
> 3. There is someone willing to do the actual work and carry out such
>   transition.  That's always the case in Debian for any kind of work.
> 
> If GNUstep upstream drops GCC support, 1) will become pointless but 2)
> and 3) remain.
> 
> If GNUstep upstream continues GCC support and the condition outlined
> in 1) does not change, we'll stick to GCC.  We will not move just
> because of some blurry promise for great new software.  I've seen this
> before and it's nothing more than a wet dream.

That‘s what I meant.
+ if clang/the gnustep runtime would support all major architectures there 
would be no regression at all. So that‘s what should be worked on.

Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Johannes Brakensiek wrote:
> On 25 Nov 2019, at 14:34, Yavor Doganov wrote:
> > Off the top of my head, Rik theme is about the single piece of
> > software that can't be built on stock Debian because of us
> > sticking to GCC.
> 
> thank you for making clear your point. I understood GNUstep would
> have to provide an updated runtime for all supported architectures
> and upstream software/applications that rely on clang and its
> features to make the Debian maintainers distribute it.

No, that was not my point and nowhere near to what I said.  Debian
will consider moving to Clang and the new runtime when:

1. The pool of new software is large and worthy enough to justify the
   major regression that is dropping support for about half of the
   architectures.  It means there has to be much more than Rik that we
   can't build and package now.  And it appears Rik is buildable with
   GCC, albeit a less capable version.  So it's not even a proper
   example.

2. The release team approves building an entire software stack with a
   non-default compiler and as a direct consequence dropping
   architecure support.

3. There is someone willing to do the actual work and carry out such
   transition.  That's always the case in Debian for any kind of work.

If GNUstep upstream drops GCC support, 1) will become pointless but 2)
and 3) remain.

If GNUstep upstream continues GCC support and the condition outlined
in 1) does not change, we'll stick to GCC.  We will not move just
because of some blurry promise for great new software.  I've seen this
before and it's nothing more than a wet dream.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

David Chisnall wrote:
> On 25 Nov 2019, at 13:37, Yavor Doganov  wrote:
> > RISC-V is the newest GNU/Linux architecture and it's not yet
> > supported by Clang.
> 
> Yavor, I appreciate that this is an emotional topic for you, but
> please can you try to confine yourself to the truth?

The truth is that none of the llvm-toolchain-* packages ever built on
Debian's ricv64 autobuilders.  Not even once.  Which means that if we
are going to build GNUstep with Clang in Debian, it won't be available
on riscv64.

This is likely to be fixed in the near future but I'm talking about
the reality now.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Maxthon Chan]

I am tempted to suggest a crazy idea: fork GNUstep, and maintain them in a 
similar fashion as Fedora versus RHEL/CentOS: same team, same general code 
base, different goal.

The fork would represent the cutting edge for GNUstep, aiming to support all 
modern Cocoa features and hopefully one day catch up to what Apple is 
releasing. This is similar to Fedora in the comparison. To begin with, the fork 
should not support GCC, instead it uses exclusively clang as the build tool. It 
would be free of GCC compatibility #define’s, and make extensive use of modern 
feature like object literals, ARC, blocks etc. The fork should be excluded from 
GNU project itself so it is relatively shielded from the FSF internal turmoil, 
although some form of copyright assignment arrangement is still needed so code 
can be merged when it is time for GNUstep proper to rebase.

The main GNUstep project is the slower compatibility-aimed version that 
maintains GCC compatibility and ships with all the compatibility patches and 
manual memory management added back. This is similar to RHEL/CentOS in the 
comparison. Main GNUstep would periodically rebase from a tag on the fork, and 
reapply all the compatibility patches so it would build using the old system.

As of Debian, they can ship both at the same time, as long as they are marked 
as conflicting packages.

> On Nov 25, 2019, at 10:07 PM, H. Nikolaus Schaller  wrote:
> 
> 
>> Am 25.11.2019 um 12:29 schrieb Gregory Casamento > >:
>> 
>> 
>> Nikolaus,
>> 
>> On Mon, Nov 25, 2019 at 6:06 AM H. Nikolaus Schaller > > wrote:
>> Because not everybody will follow your focus. GNUstep is not a for-profit 
>> organization.
>> 
>> I'm well aware of this.  I've been with the project since 1999.  Lead 
>> maintainer since 2008 and maintainer of Gorm since 2002.
>> 
>> It's a thankless job, believe me.  No one can know until they have held it.  
>> I simultaneously take the blame for all of the decisions made on the project 
>> whether they are mine or not and I am unable to effect unilateral change.
> 
> I believe that and do not at all doubt, since I have been in several project 
> leaders roles myself in the past... It is like tending fleas. And it is
> often minimizing contradiction, because it turns out to be rare that all 
> decisions are accepted by everybody (although that is always my goal).
> Therefore I try to find creative-and solutions which means that in an 
> either-or decision situation I try to find a way to include both of the
> initially exclusive options. This may turn out to be very difficult.
> 
> Since I have to admit that I never did: let me express my thanks here for 
> taking this role!
> And congrats for 20 year's anniversary of participation.
> I think I came in first contact with GNUstep in Sept 2002 (at least this is 
> the first mail of this list I can find) and GNUstep has moved forward 
> significantly during that time.
> 
>> My job is to act for the greater good of the project and that is what I am 
>> attempting to do here.
> 
> Sure and I do not doubt that. I just have a slightly different opinion what 
> the right moment to deprecate some fundamental component
> (compiler) where everything is based on. And before breaking down the 
> basement I'd try to repair it.
> 

Re: Which ObjC2.0 features are missing in the latest GCC?

[David Chisnall]

On 25 Nov 2019, at 13:37, Yavor Doganov  wrote:
> 
> RISC-V is the newest GNU/Linux architecture and it's not yet supported
> by Clang.

Yavor, I appreciate that this is an emotional topic for you, but please can you 
try to confine yourself to the truth?  RISC-V is a supported architecture by 
LLVM and has been for quite a while.  The author of the LLVM Weekly blog series 
is the RISC-V LLVM maintainer and is employed to work on it full time by the 
lowRISC project.  At the last LLVM DevMeeting, there were representatives from 
half a dozen companies shipping RISC-V products, all investing in LLVM.

David

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 25.11.2019 um 12:29 schrieb Gregory Casamento :
> 
> 
> Nikolaus,
> 
> On Mon, Nov 25, 2019 at 6:06 AM H. Nikolaus Schaller  > wrote:
> Because not everybody will follow your focus. GNUstep is not a for-profit 
> organization.
> 
> I'm well aware of this.  I've been with the project since 1999.  Lead 
> maintainer since 2008 and maintainer of Gorm since 2002.
> 
> It's a thankless job, believe me.  No one can know until they have held it.  
> I simultaneously take the blame for all of the decisions made on the project 
> whether they are mine or not and I am unable to effect unilateral change.

I believe that and do not at all doubt, since I have been in several project 
leaders roles myself in the past... It is like tending fleas. And it is
often minimizing contradiction, because it turns out to be rare that all 
decisions are accepted by everybody (although that is always my goal).
Therefore I try to find creative-and solutions which means that in an either-or 
decision situation I try to find a way to include both of the
initially exclusive options. This may turn out to be very difficult.

Since I have to admit that I never did: let me express my thanks here for 
taking this role!
And congrats for 20 year's anniversary of participation.
I think I came in first contact with GNUstep in Sept 2002 (at least this is the 
first mail of this list I can find) and GNUstep has moved forward significantly 
during that time.

> My job is to act for the greater good of the project and that is what I am 
> attempting to do here.

Sure and I do not doubt that. I just have a slightly different opinion what the 
right moment to deprecate some fundamental component
(compiler) where everything is based on. And before breaking down the basement 
I'd try to repair it.

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 25.11.2019 um 12:09 schrieb David Chisnall :
> 
> On 25 Nov 2019, at 10:18, H. Nikolaus Schaller  wrote:
>> 
>> Fred mentioned that it could be possible to define some block wrapper macros 
>> if some time is invested.
>> It that works out, we do not make our decisions depend on gcc *not* 
>> implementing something.
> 
> Fred made this claim, but he also added the caveat that it would likely be 
> limited to blocks with no captures.  In this, I believe that he’s right.
> Consider this trivial compilation unit:
> 
> ```
> @interface X
> - (void)doSomething;
> @end
> 
> typedef void(^block)(void);
> 
> block callMethodOn(id x)
> {
>   return ^() { [x doSomething]; };
> }

That is indeed a challenge.

To show how it would be used:

block b = callMethodOn(object);

b();// void return, void arguments should do [object doSomething];

> ```
> 
> A few things to notice:
> 
> 1. This single function generates 4 functions.
> 2. The copy and dispose helpers have to understand the offset of each of the 
> captures.  This is fairly simple in this example, because there’s only one 
> capture.
> 3. To avoid bloating the binaries, the copy and destroy helpers have 
> well-known names and COMDATs, so the linker can eliminate duplicates.
> 4. The memory management around creating the block and its captures is 
> non-trivial.  Note that this is compiled with ARC, blocks for Objective-C 
> implement a subset of ARC even in non-ARC mode because getting the memory 
> management right was considered too hard.
> 
> If, every time you want to write something as simple as the original 
> Objective-C source, you have to write something as complex as the LLVM output,

I am not sure that this is the only way to implement it.

First of all the callMethodOn returns some block which is a data structure 
knowing that it should take the parameter x and do some function.
Let's call it NSBlock. NSBlock can be an ordinary object like any other so that 
it can follow the same memory management rules as used otherwise.

So a first draft (without being able to think about all exceptions and corner 
cases - it is impossible to catch up years of clang development in minutes), 
what about translating this to:

> @interface X
> - (void)doSomething;
> @end

typedef NSBlock *block;

block callMethodOn(id x)
{
fn(id x) { [x doSomething]; }
NSBlock *b=[NSBlock new];
[b setParameterList:x]; // use va_list or NSInvocation something - can 
retain the object x
[b setFunction:fn];
return block;
}

Then you can do

[block run]

assuming that NSBlock has a -run method (and perhaps a runWithArgs) which does

([self function])([self parameterList])

I haven't worked out all details but it might be possible to put that all into 
wrapper macros
that either translate into ^ notation or into some ObjC code as sketched above.

Yes, syntax is then a little more complex than the ^notation.

Just some idea and Fred may comment on what he had in mind.

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 25.11.2019 um 12:25 schrieb Gregory Casamento :
> 
> On Mon, Nov 25, 2019 at 6:05 AM H. Nikolaus Schaller  > wrote:
> Please count me as manpower you loose by deprecating GCC (even if I 
> contribute only indirectly through my project mySTEP). So this is not a 
> simple reprioritization.
> 
> A somewhat dispassionate question so don't take this the wrong way: Does the 
> value you add equal or exceed the gain which might be achieved by the rest of 
> the project if we lose gcc?

Hm. How should I be able to decide that in advance? Time will tell...

Re: Which ObjC2.0 features are missing in the latest GCC?

[Johannes Brakensiek]

Hi Yavor,

On 25 Nov 2019, at 14:34, Yavor Doganov wrote:


Off the top of my head, Rik theme is about the single piece of
software that can't be built on stock Debian because of us sticking to
GCC.  NEXTSPACE relies on custom patches to GNUstep core, which means
that you'll have to build your own GNUstep environment anyway so you
may as well configure it for Clang and the new runtime.


thank you for making clear your point. I understood GNUstep would have 
to provide an updated runtime for all supported architectures and 
upstream software/applications that rely on clang and its features to 
make the Debian maintainers distribute it.


It’s good to know what to do now. ;)

Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Bertrand Dekoninck wrote:
> > Le 24 nov. 2019 à 02:24, Yavor Doganov  a écrit :
> > except probably the Rik theme
> 
> Just my two pence here : I’ve got a gcc compatible branch of rik
> (which I maintain for my ppc computers) at 
> https://github.com/BertrandDekoninck/rik.theme/tree/no_objc2

Thanks, I didn't know about this.  It was on my TODO to make it build
with GCC so it's great that it's done already.

The main reason why the Rik theme is not yet packaged for Debian is
because there's been no release yet.  I feel uncomfortable to package
software that is unreleased as it can be damaging for the upstream
developers' reputation in case there are still known bugs, etc.  I
know the theory that "every new commit is a new release" but it only
works if the downstream maintainer is familiar with the code and can
exercise proper judgement what snapshot to put in a stable distro
release.

(FYI, Debian doesn't require generated tarballs, a Git tag will
suffice.  Preferably signed.)

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Gregory Casamento wrote:
> On Fri, Nov 22, 2019 at 3:01 PM Yavor Doganov  wrote:
> > The answer is simple: because there's a lot to lose and nothing to
> > gain.

> This is patently incorrect.  The gain is time and compatibility with
> the latest code base.  I laid out the advantages and disadvantages
> of this in my previous posting.

There are no advantages for the current GNUstep packages in Debian
which is the main point I was trying to make.  I don't dispute the
fact that dropping support for GCC will simplify things a lot for
you.  At certain cost, of course, which you consider negligible.

> * More Applications, more applications means more end users (sort of
> chicken and egg thing)

That's purely hypothetical to the extent of being mere speculation.
GNUstep supports Clang and David's runtime for quite some time now,
why there are no more applications?  Why existing GNUstep applications
have not been updated to take advantage of the new features?

> What's to lose:
> * Possibly a political issue with the FSF, but there are other projects
> which depend on languages not implemented by GCC.

I'm not aware of any GNU package written in a compiled language that
cannot be built with GCC.

I don't know what you mean by "political issue" but such a drastic
change should be discussed with the GNU Project of which GNUstep is
still part of.  It is wrong to decide it with a vote that doesn't even
specify simple things like who is eligible to vote and based on what
majority the decision is going to be taken.  As a GNU maintainer you
should know these things.

> * Support for older platforms which ONLY support gcc.

RISC-V is the newest GNU/Linux architecture and it's not yet supported
by Clang.

> So, I apologize if I don't agree with the "nothing to gain" opinion.

You are free to disagree.  But as it often happens with real life, the
loss may become obvious only post factum...  You could be left only
with the "gain" which may not look like a big gain then.  It could
even look more like you have shot yourself in the foot.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Johannes Brakensiek wrote:
> On 24 Nov 2019, at 14:16, Yavor Doganov wrote:
> > Packaging libraries and development tools just because they are cool
> > and it is expected that hordes of developers will write useful
> > programs that utilize them is not a useful activity -- you have to
> > justify their inclusion in the distro and a hypothetical future
> > benefit is not a good argument.
> 
> Well, I think different about this (otherwise Apple f.e. would never
> have shipped any new software I think), but we can agree to disagree
> here.

TBH, I don't give a flying flute what Apple ships and how; it is
irrelevant anyway.  I described the way things work in the Free World
and Debian, in particular.

> I also typed apt-get install gnustep-devel and I was provided an IDE
> that looked like it jumped out of the 90s.

JFTR, you'd get exactly the same IDE with exactly the same
capabilities if GNUstep was configured to use the "modern" features.

> I thought: Oh, not that bad, I can use Xcode and compile then. But I
> could not because the tools installed were not able to compile
> f.e. Rik.theme or .m files using recent language features.

Off the top of my head, Rik theme is about the single piece of
software that can't be built on stock Debian because of us sticking to
GCC.  NEXTSPACE relies on custom patches to GNUstep core, which means
that you'll have to build your own GNUstep environment anyway so you
may as well configure it for Clang and the new runtime.

> So, please tell me which part of this story sounds most ridiculous
> to you?

The part that developers are waiting for Debian to move to Clang so
that they can start writing free GNUstep software.

> > Are these projects directly buildable/runnable with GNUstep
> > configured for Clang and the modern runtime?  I doubt it.
> 
> No, of course they are not. But they could some day if the GNUstep
> project would decide and be able to develop some way further. That’s
> my point.

And that is exactly my point.  There are other major obstacles to
porting free Cocoa software; switching to Clang will not help.
Therefore, the argument that a move to Clang will bring us new free
software is moot.

What will happen "some day", we don't know.  Chances are that there
will be a gazillion of new features that these Cocoa apps require and
GNUstep doesn't yet implement.  At least this is the evidence from the
past few decades.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Gregory Casamento]

Nikolaus,

On Mon, Nov 25, 2019 at 6:06 AM H. Nikolaus Schaller 
wrote:

> Because not everybody will follow your focus. GNUstep is not a for-profit
> organization.
>

I'm well aware of this.  I've been with the project since 1999.  Lead
maintainer since 2008 and maintainer of Gorm since 2002.

It's a thankless job, believe me.  No one can know until they have held
it.  I simultaneously take the blame for all of the decisions made on the
project whether they are mine or not and I am unable to effect unilateral
change.

My job is to act for the greater good of the project and that is what I am
attempting to do here.

GC
-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Re: Which ObjC2.0 features are missing in the latest GCC?

[Gregory Casamento]

On Mon, Nov 25, 2019 at 6:05 AM H. Nikolaus Schaller 
wrote:

> Please count me as manpower you loose by deprecating GCC (even if I
> contribute only indirectly through my project mySTEP). So this is not a
> simple reprioritization.
>

A somewhat dispassionate question so don't take this the wrong way: Does
the value you add equal or exceed the gain which might be achieved by the
rest of the project if we lose gcc?

GC
-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Re: Which ObjC2.0 features are missing in the latest GCC?

[Matt Rice]

On Mon, Nov 25, 2019 at 10:53 AM David Chisnall
 wrote:
>
> On 25 Nov 2019, at 09:37, Gregory Casamento  wrote:
> >
> > * C++, while this is not exclusive to clang, gcc doesn't support the latest 
> > version of C++.  Clang is extraordinarily good at optimization.
>
> I don’t think this is true.  We have a C++17 project that we test in CI with 
> GCC.  The only times that we experience problems are when we use some 
> non-standard attributes that GCC doesn’t support (but we also build with 
> Visual Studio, so we rarely find anything that we need that those two support 
> but GCC doesn’t, it’s only when we have something ELF-specific that’s a 
> problem).
>
> I don’t know how good GCC’s Objective-C++ support is (as I recall, 
> Objective-C and Objective-C++ in GCC aren’t just base-language + Objective-*, 
> so it isn’t necessarily a given that you get full C++17 support in GCC’s 
> Objective-C++), but using C++ smart pointers you can get a lot of ARC (at the 
> very least - and prior to ARC support, I did - you can implement smart 
> pointers that manage Objective-C retain / release and use them to hold 
> Objective-C objects in collections.

I had used ObjC++ before when embedding a c++ rendering engine in an
NSOpenGLView,
many years ago, but I don't recall anything specifically in the objc++
frontend that did anything but punt to either the objc or c++ backend.

What I do remember is that the debugging support is terrible!
It implements Dwarf with the language ObjC++, and then in the
debuginfo Classes in objc are mapped to dwarf's Object/Class thing,
and classes in C++ are mapped to the same Object/Class thing.

Apple's debugger tells the difference by looking at symbol mangling,
In particular their objc symbols contain +-[()]: characters, and it
can tell from the first character if it's objective-c or not.
A solution like that was never really acceptable for gdb.

So you generally had to set language to c++, or objc at every step.
This is very unlikely to have changed for gcc, is it any better on clang?

Re: Which ObjC2.0 features are missing in the latest GCC?

[David Chisnall]

On 25 Nov 2019, at 10:18, H. Nikolaus Schaller  wrote:
> 
> Fred mentioned that it could be possible to define some block wrapper macros 
> if some time is invested.
> It that works out, we do not make our decisions depend on gcc *not* 
> implementing something.

Fred made this claim, but he also added the caveat that it would likely be 
limited to blocks with no captures.  In this, I believe that he’s right.  A 
stateless block is:

 - A function that’s used when you invoke the block.
 - A fixed structure describing the block, its type encoding and a couple of 
other things.

Stateful blocks also add a load of fields on the end that describe how to copy 
and destroy each of the captures.  For blocks to actually be useful, you need 
state.  You can’t, with C macros, implement something that defines a load of 
functions inline.  You probably could create a set of macros that would 
simplify the effort in building the block byval structures, but it’s still 
non-trivial.

Note that it is probably possible (though verbose) to implement this using C++ 
templates (though matching the ABI is tricky).  I think most people reading 
this have no idea how complex the block generation code is.  When I implemented 
Pragmatic Smalltalk, I write compiler support for a subset of the blocks ABI 
and that was a few hundred lines of code for the compiler.  Doing the same in 
metaprogramming (especially with C macros) would be incredibly hard.


Consider this trivial compilation unit:

```
@interface X
- (void)doSomething;
@end

typedef void(^block)(void);

block callMethodOn(id x)
{
return ^() { [x doSomething]; };
}
```

Now, when I run this through clang, this is what I get out as LLVM IR (eliding 
everything that isn’t directly related to blocks):

```
%struct.__block_descriptor = type { i64, i64 }

$__copy_helper_block_e8_32s = comdat any

$__destroy_helper_block_e8_32s = comdat any


@"__block_descriptor_40_e8_32s_e5_v8\01?0l" = linkonce_odr hidden unnamed_addr 
constant { i64, i64, i8*, i8*, i8*, i8* } { i64 0, i64 40, i8* bitcast (void 
(i8*, i8*)* @__copy_helper_block_e8_32s to i8*), i8* bitcast (void (i8*)* 
@__destroy_helper_block_e8_32s to i8*), i8* getelementptr inbounds ([6 x i8], 
[6 x i8]* @.str, i32 0, i32 0), i8* null }, align 8

; Function Attrs: nounwind uwtable
define dso_local void ()* @callMethodOn(i8*) local_unnamed_addr #0 {
  %2 = alloca <{ i8*, i32, i32, i8*, %struct.__block_descriptor*, i8* }>, align 
8
  %3 = tail call i8* @llvm.objc.retain(i8* %0) #1
  %4 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 5
  %5 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 0
  store i8* bitcast (i8** @_NSConcreteStackBlock to i8*), i8** %5, align 8
  %6 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 1
  store i32 -1040187392, i32* %6, align 8
  %7 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 2
  store i32 0, i32* %7, align 4
  %8 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 3
  store i8* bitcast (void (i8*)* @__callMethodOn_block_invoke to i8*), i8** %8, 
align 8
  %9 = getelementptr inbounds <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>, <{ i8*, i32, i32, i8*, 
%struct.__block_descriptor*, i8* }>* %2, i64 0, i32 4
  store %struct.__block_descriptor* bitcast ({ i64, i64, i8*, i8*, i8*, i8* }* 
@"__block_descriptor_40_e8_32s_e5_v8\01?0l" to %struct.__block_descriptor*), 
%struct.__block_descriptor** %9, align 8
  store i8* %0, i8** %4, align 8, !tbaa !2
  %10 = bitcast <{ i8*, i32, i32, i8*, %struct.__block_descriptor*, i8* }>* %2 
to void ()*
  %11 = bitcast void ()* %10 to i8*
  %12 = tail call i8* @llvm.objc.retain(i8* %0) #1
  %13 = call i8* @llvm.objc.retainBlock(i8* nonnull %11) #1, 
!clang.arc.copy_on_escape !5
  %14 = bitcast i8* %13 to void ()*
  %15 = load i8*, i8** %4, align 8
  call void @llvm.objc.release(i8* %15) #1, !clang.imprecise_release !5
  call void @llvm.objc.release(i8* %0) #1, !clang.imprecise_release !5
  %16 = tail call i8* @llvm.objc.autoreleaseReturnValue(i8* %13) #1
  ret void ()* %14
}

; Function Attrs: nounwind
declare i8* @llvm.objc.retain(i8*) #1

; Function Attrs: uwtable
define internal void @__callMethodOn_block_invoke(i8* nocapture readonly) #2 {
  %2 = getelementptr inbounds i8, i8* %0, i64 32
  %3 = bitcast i8* %2 to i8**
  %4 = load i8*, i8** %3, align 8, !tbaa !2
  tail call void bitcast (i8* (i8*, ...)* @objc_msgSend to void (i8*, 
i8*)*)(i8* %4, i8* bitcast ({ i8*, i8* }* 

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 25.11.2019 um 11:59 schrieb Gregory Casamento :
> 
> 
> Nikolaus,
> 
> On Mon, Nov 25, 2019 at 5:51 AM H. Nikolaus Schaller  > wrote:
> 
>> Am 25.11.2019 um 11:41 schrieb Maxthon Chan > >:
>> 
>> Where should we put the creativity to though?
> 
> The highest level of creativity is to do both
> 
> This is entirely subjective.  Why shouldn't we focus?

Because not everybody will follow your focus. GNUstep is not a for-profit 
organization.

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 25.11.2019 um 11:55 schrieb Maxthon Chan :
> 
> 
> 
>> On Nov 25, 2019, at 6:51 PM, H. Nikolaus Schaller > > wrote:
>> 
>> 
>>> Am 25.11.2019 um 11:41 schrieb Maxthon Chan >> >:
>>> 
>>> Where should we put the creativity to though?
>> 
>> The highest level of creativity is to do both
> 
> We only have a limited amount of manpower, so we have to prioritize. If we 
> stick to GCC we have to fix a lot of compiler incompatibilities before even 
> attempting anything new, let alone having to drag some vey legacy language 
> features along. The main point of moving to clang only is to liberate those 
> manpower from fixing those incompatibilities and put them into creating 
> something new.

Please count me as manpower you loose by deprecating GCC (even if I contribute 
only indirectly through my project mySTEP). So this is not a simple 
reprioritization.

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 25.11.2019 um 11:44 schrieb Gregory Casamento :
> 
> Nikolaus,
> 
> With respect...
> 
> On Mon, Nov 25, 2019 at 5:18 AM H. Nikolaus Schaller  > wrote:
> I know that I likely start a flame war, but watching the discussion from an 
> elevated point of view...
> 
> Elevated?

Yes. Taking three steps back (and upwards) from discussing the details of gcc 
vs. clang or its benefits. But looking on GNUstep as a project with goals, 
people etc.

>  
> > Am 25.11.2019 um 10:30 schrieb Gregory Casamento  > >:
> > * Compatibility, much of the API is moving towards using blocks. Blocks 
> > *ARE NOT SUPPORTED* on GCC and aren't likely to be anytime in the near 
> > future.
> 
> Hm, where has our own creativity gone?
> 
> Mine, personally, nowhere.  I've been putting a great amount of work into 
> this project as of late.  Where should our creativity be spent?  Bridging the 
> gap between an old version of the language and it's successor or debugging 
> and building new functionality in GS?

All of them. That is what made Apple and Cocoa a better and more stable 
development platform than other big OS I know of. And even is nowadays. There 
are methods deprecated in 10.2 still work in 10.14. So Apple did spend a lot of 
time not to break old software and that is superior to "just install a newer 
version of this and that - and live with that it breaks something unreleated". 
Unfortunately this attitude seems to have eroded.

>  
> Fred mentioned that it could be possible to define some block wrapper macros 
> if some time is invested.
> It that works out, we do not make our decisions depend on gcc *not* 
> implementing something.
> 
> I have no problem with bridging the gap, but shall we continue to do so?  
> Where can we draw the line?  The only thing we are doing by constantly doing 
> this is, as you said some time needs to be invested... is wasting time.   We 
> are delaying the inevitable.

Fred did talk about a weekend if I remember correctly. I do not know if it 
really can be done that quickly. But all other tasks and frameworks you want to 
do better once gcc is no longer supported take years...

> 
> So this argument for moving to clang looks more like an excuse that we do not 
> work on our own gcc compatible solution, isn't it?
> 
> Given the list of things that I have mentioned as advantages, it's far from 
> an excuse.   I am simply advocating that we make things simpler for our 
> developers and, potential contributors. Pretending or casting it as an 
> "excuse" minimizes the weight of the argument without actually arguing the 
> point.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Gregory Casamento]

Ah, okay.  So I guess we can take that off of the list of advantages.  I
believe, however, that clang is better at optimization.  I could be wrong
on that point.

On Mon, Nov 25, 2019 at 5:53 AM David Chisnall 
wrote:

> On 25 Nov 2019, at 09:37, Gregory Casamento 
> wrote:
> >
> > * C++, while this is not exclusive to clang, gcc doesn't support the
> latest version of C++.  Clang is extraordinarily good at optimization.
>
> I don’t think this is true.  We have a C++17 project that we test in CI
> with GCC.  The only times that we experience problems are when we use some
> non-standard attributes that GCC doesn’t support (but we also build with
> Visual Studio, so we rarely find anything that we need that those two
> support but GCC doesn’t, it’s only when we have something ELF-specific
> that’s a problem).
>
> I don’t know how good GCC’s Objective-C++ support is (as I recall,
> Objective-C and Objective-C++ in GCC aren’t just base-language +
> Objective-*, so it isn’t necessarily a given that you get full C++17
> support in GCC’s Objective-C++), but using C++ smart pointers you can get a
> lot of ARC (at the very least - and prior to ARC support, I did - you can
> implement smart pointers that manage Objective-C retain / release and use
> them to hold Objective-C objects in collections.
>
> David
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Re: Which ObjC2.0 features are missing in the latest GCC?

[Gregory Casamento]

Nikolaus,

On Mon, Nov 25, 2019 at 5:51 AM H. Nikolaus Schaller 
wrote:

>
> Am 25.11.2019 um 11:41 schrieb Maxthon Chan :
>
> Where should we put the creativity to though?
>
>
> The highest level of creativity is to do both
>

This is entirely subjective.  Why shouldn't we focus?

GC

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Re: Which ObjC2.0 features are missing in the latest GCC?

[Maxthon Chan]

> On Nov 25, 2019, at 6:51 PM, H. Nikolaus Schaller  wrote:
> 
> 
>> Am 25.11.2019 um 11:41 schrieb Maxthon Chan > >:
>> 
>> Where should we put the creativity to though?
> 
> The highest level of creativity is to do both

We only have a limited amount of manpower, so we have to prioritize. If we 
stick to GCC we have to fix a lot of compiler incompatibilities before even 
attempting anything new, let alone having to drag some vey legacy language 
features along. The main point of moving to clang only is to liberate those 
manpower from fixing those incompatibilities and put them into creating 
something new.

Re: Which ObjC2.0 features are missing in the latest GCC?

[David Chisnall]

On 25 Nov 2019, at 09:37, Gregory Casamento  wrote:
> 
> * C++, while this is not exclusive to clang, gcc doesn't support the latest 
> version of C++.  Clang is extraordinarily good at optimization.

I don’t think this is true.  We have a C++17 project that we test in CI with 
GCC.  The only times that we experience problems are when we use some 
non-standard attributes that GCC doesn’t support (but we also build with Visual 
Studio, so we rarely find anything that we need that those two support but GCC 
doesn’t, it’s only when we have something ELF-specific that’s a problem).

I don’t know how good GCC’s Objective-C++ support is (as I recall, Objective-C 
and Objective-C++ in GCC aren’t just base-language + Objective-*, so it isn’t 
necessarily a given that you get full C++17 support in GCC’s Objective-C++), 
but using C++ smart pointers you can get a lot of ARC (at the very least - and 
prior to ARC support, I did - you can implement smart pointers that manage 
Objective-C retain / release and use them to hold Objective-C objects in 
collections.

David

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 25.11.2019 um 11:41 schrieb Maxthon Chan :
> 
> Where should we put the creativity to though?

The highest level of creativity is to do both

> I would argue that some better places for our creativity to go towards would 
> be things like our own updating Base, CoreBase and GUI to cover all modern 
> Cocoa API, Swift standard library, GNUstep Back compatible CocoaTouch and 
> SwiftUI implementation, Vulcan-based Metal, SpriteKit and SceneKit 
> reimplementation etc.
> 
> Oh since I mentioned it, if we want to try implementing Metal, we have to fix 
> Objective-C++ first, which requires clang. GCC’s version of Objective-C is 
> too broken to support modern features.
> 
> If I recalled it right, some modern Objective-C and Swift features even 
> requires the use of LLVM libc++ and libc++abi instead of GCC libstdc++.


> 
>> On Nov 25, 2019, at 6:27 PM, H. Nikolaus Schaller > > wrote:
>> 
>>> 
>>> Am 25.11.2019 um 11:21 schrieb Andreas Fink >> >:
>>> 
>>> 
 On 25 Nov 2019, at 11:18, H. Nikolaus Schaller >>> > wrote:
 
 I know that I likely start a flame war, but watching the discussion from 
 an elevated point of view...
 
> Am 25.11.2019 um 10:30 schrieb Gregory Casamento 
> mailto:greg.casame...@gmail.com>>:
> * Compatibility, much of the API is moving towards using blocks. Blocks 
> *ARE NOT SUPPORTED* on GCC and aren't likely to be anytime in the near 
> future.
 
 Hm, where has our own creativity gone?
 
 Fred mentioned that it could be possible to define some block wrapper 
 macros if some time is invested.
 It that works out, we do not make our decisions depend on gcc *not* 
 implementing something.
 
 So this argument for moving to clang looks more like an excuse that we do 
 not work on our own gcc compatible solution, isn't it?
 
 -- hns
>>> 
>>> using the same argument you can say we could use assember by creating some 
>>> tools to output assembler first.
>> 
>> No. We are not talking about different language hierarchies but the same and 
>> one language feature.
>> 
>>> As David pointed out, its a  hell of a lot of work for no benefit and 
>>> dragging along old workarounds which lead to problems and performance 
>>> impacts.
>> 
>> Have you even tried? And evaluated what the workarounds and performance 
>> impacts are?
>> 
>> Nobody has, but you already argue against it. That seems to confirm my 
>> argument that we have lost creativity...
> 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Gregory Casamento]

Nikolaus,

With respect...

On Mon, Nov 25, 2019 at 5:18 AM H. Nikolaus Schaller 
wrote:

> I know that I likely start a flame war, but watching the discussion from
> an elevated point of view...
>

Elevated?


> > Am 25.11.2019 um 10:30 schrieb Gregory Casamento <
> greg.casame...@gmail.com>:
> > * Compatibility, much of the API is moving towards using blocks. Blocks
> *ARE NOT SUPPORTED* on GCC and aren't likely to be anytime in the near
> future.
>
> Hm, where has our own creativity gone?


Mine, personally, nowhere.  I've been putting a great amount of work into
this project as of late.  Where should our creativity be spent?  Bridging
the gap between an old version of the language and it's successor or
debugging and building new functionality in GS?


> Fred mentioned that it could be possible to define some block wrapper
> macros if some time is invested.
> It that works out, we do not make our decisions depend on gcc *not*
> implementing something.
>

I have no problem with bridging the gap, but shall we continue to do so?
Where can we draw the line?  The only thing we are doing by constantly
doing this is, as you said some time needs to be invested... is wasting
time.   We are delaying the inevitable.

So this argument for moving to clang looks more like an excuse that we do
> not work on our own gcc compatible solution, isn't it?
>

Given the list of things that I have mentioned as advantages, it's far from
an excuse.   I am simply advocating that we make things simpler for our
developers and, potential contributors. Pretending or casting it as an
"excuse" minimizes the weight of the argument without actually arguing the
point.

-- hns
>

GC
-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

[image: Mailtrack]

Sender
notified by
Mailtrack

11/25/19,
05:42:56 AM

Re: Which ObjC2.0 features are missing in the latest GCC?

[Maxthon Chan]

Where should we put the creativity to though?

I would argue that some better places for our creativity to go towards would be 
things like our own updating Base, CoreBase and GUI to cover all modern Cocoa 
API, Swift standard library, GNUstep Back compatible CocoaTouch and SwiftUI 
implementation, Vulcan-based Metal, SpriteKit and SceneKit reimplementation etc.

Oh since I mentioned it, if we want to try implementing Metal, we have to fix 
Objective-C++ first, which requires clang. GCC’s version of Objective-C is too 
broken to support modern features.

If I recalled it right, some modern Objective-C and Swift features even 
requires the use of LLVM libc++ and libc++abi instead of GCC libstdc++.

> On Nov 25, 2019, at 6:27 PM, H. Nikolaus Schaller  wrote:
> 
>> 
>> Am 25.11.2019 um 11:21 schrieb Andreas Fink :
>> 
>> 
>>> On 25 Nov 2019, at 11:18, H. Nikolaus Schaller  wrote:
>>> 
>>> I know that I likely start a flame war, but watching the discussion from an 
>>> elevated point of view...
>>> 
 Am 25.11.2019 um 10:30 schrieb Gregory Casamento 
 :
 * Compatibility, much of the API is moving towards using blocks. Blocks 
 *ARE NOT SUPPORTED* on GCC and aren't likely to be anytime in the near 
 future.
>>> 
>>> Hm, where has our own creativity gone?
>>> 
>>> Fred mentioned that it could be possible to define some block wrapper 
>>> macros if some time is invested.
>>> It that works out, we do not make our decisions depend on gcc *not* 
>>> implementing something.
>>> 
>>> So this argument for moving to clang looks more like an excuse that we do 
>>> not work on our own gcc compatible solution, isn't it?
>>> 
>>> -- hns
>> 
>> using the same argument you can say we could use assember by creating some 
>> tools to output assembler first.
> 
> No. We are not talking about different language hierarchies but the same and 
> one language feature.
> 
>> As David pointed out, its a  hell of a lot of work for no benefit and 
>> dragging along old workarounds which lead to problems and performance 
>> impacts.
> 
> Have you even tried? And evaluated what the workarounds and performance 
> impacts are?
> 
> Nobody has, but you already argue against it. That seems to confirm my 
> argument that we have lost creativity...

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 25.11.2019 um 11:21 schrieb Andreas Fink :
> 
> 
>> On 25 Nov 2019, at 11:18, H. Nikolaus Schaller  wrote:
>> 
>> I know that I likely start a flame war, but watching the discussion from an 
>> elevated point of view...
>> 
>>> Am 25.11.2019 um 10:30 schrieb Gregory Casamento :
>>> * Compatibility, much of the API is moving towards using blocks. Blocks 
>>> *ARE NOT SUPPORTED* on GCC and aren't likely to be anytime in the near 
>>> future.
>> 
>> Hm, where has our own creativity gone?
>> 
>> Fred mentioned that it could be possible to define some block wrapper macros 
>> if some time is invested.
>> It that works out, we do not make our decisions depend on gcc *not* 
>> implementing something.
>> 
>> So this argument for moving to clang looks more like an excuse that we do 
>> not work on our own gcc compatible solution, isn't it?
>> 
>> -- hns
> 
> using the same argument you can say we could use assember by creating some 
> tools to output assembler first.

No. We are not talking about different language hierarchies but the same and 
one language feature.

> As David pointed out, its a  hell of a lot of work for no benefit and 
> dragging along old workarounds which lead to problems and performance impacts.

Have you even tried? And evaluated what the workarounds and performance impacts 
are?

Nobody has, but you already argue against it. That seems to confirm my argument 
that we have lost creativity...

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 25 Nov 2019, at 11:18, H. Nikolaus Schaller  wrote:
> 
> I know that I likely start a flame war, but watching the discussion from an 
> elevated point of view...
> 
>> Am 25.11.2019 um 10:30 schrieb Gregory Casamento :
>> * Compatibility, much of the API is moving towards using blocks. Blocks *ARE 
>> NOT SUPPORTED* on GCC and aren't likely to be anytime in the near future.
> 
> Hm, where has our own creativity gone?
> 
> Fred mentioned that it could be possible to define some block wrapper macros 
> if some time is invested.
> It that works out, we do not make our decisions depend on gcc *not* 
> implementing something.
> 
> So this argument for moving to clang looks more like an excuse that we do not 
> work on our own gcc compatible solution, isn't it?
> 
> -- hns

using the same argument you can say we could use assember by creating some 
tools to output assembler first.
As David pointed out, its a  hell of a lot of work for no benefit and dragging 
along old workarounds which lead to problems and performance impacts.

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

I know that I likely start a flame war, but watching the discussion from an 
elevated point of view...

> Am 25.11.2019 um 10:30 schrieb Gregory Casamento :
> * Compatibility, much of the API is moving towards using blocks. Blocks *ARE 
> NOT SUPPORTED* on GCC and aren't likely to be anytime in the near future.

Hm, where has our own creativity gone?

Fred mentioned that it could be possible to define some block wrapper macros if 
some time is invested.
It that works out, we do not make our decisions depend on gcc *not* 
implementing something.

So this argument for moving to clang looks more like an excuse that we do not 
work on our own gcc compatible solution, isn't it?

-- hns

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 25.11.2019 um 10:37 schrieb Gregory Casamento :
> 
> I forgot...
> 
> "What's to gain" should also contain:
> 
> * Simplification of the code.  We will not have to use any #define macros in 
> order to bridge the gap between what are, essentially, two different 
> languages.

I think this is the core of the discussion, that we are talking about two 
different languages.

So what is the language of GNUstep?
Should GNUstep follow the turns defined by Apple and clang and give up its own 
direction - or should it drive straight ahead with what is here?

I.e. is GNUstep a follower for some not-well-defined mainstream or does it have 
its own goals and directions?

-- hns

Re: Which ObjC2.0 features are missing in the latest GCC?

[Gregory Casamento]

I forgot...

"What's to gain" should also contain:

* Simplification of the code.  We will not have to use any #define macros
in order to bridge the gap between what are, essentially, two different
languages.
* C++, while this is not exclusive to clang, gcc doesn't support the latest
version of C++.  Clang is extraordinarily good at optimization.
* Performance, Since clang optimizes so well, we could replace some
critical things which are currently written in C with better versions
written in C++.  David already mentioned GSIMap.  There are others.

So, yeah... I am not sure what else, but there might be more.

Yours, GC

On Mon, Nov 25, 2019 at 4:30 AM Gregory Casamento 
wrote:

> Yavor,
>
>
> On Fri, Nov 22, 2019 at 3:01 PM Yavor Doganov  wrote:
>
>> [ Posting this via NNTP, hope it works. ]
>>
>> Ivan Vučica wrote:
>> > Distro packagers should also voice their opinion on whether they can
>> > switch to Clang (and, hopefully, libobjc2), which I'd invite them to
>> > do no matter what the decision is on presence of Clang-dependent
>> > code in GNUstep core libs.
>>
>> I guess distro packagers who prefer Clang (or have no reasonable
>> choice as that is the default and perhaps the only compiler on their
>> distro) have made their choice already.
>>
>> Regarding Debian, I would like to point out that I cannot speak for
>> them.  I am neither a Debian Developer nor a Debian Maintainer.  I
>> also cannot speak for the Debian GNUstep team as I don't hold any
>> special position there.
>>
>> But I'll have to repeat what I've said several times to fellow team
>> members and other people asking me the question "Why Debian's GNUstep
>> doesn't switch to Clang?".  The answer is simple: because there's a
>> lot to lose and nothing to gain.
>>
>
> This is patently incorrect.  The gain is time and compatibility with the
> latest code base.   I laid out the advantages and disadvantages of this in
> my previous posting.  I entail you to look that post up, but I will put
> what I think the losses and the gains are here for your convenience:
>
> Switching to clang...
> What's to gain:
> * Time, time spent doing things the compiler can do automatically is a
> waste of time and, more importantly, time NOT spent on fixing or working on
> the CORE problems.
> * Compatibility, much of the API is moving towards using blocks. Blocks
> *ARE NOT SUPPORTED* on GCC and aren't likely to be anytime in the near
> future.
> * Developers, gaining developer interest means more applications.
> Supporting an up to date version of the language which is in line with
> developer expectations helps to attract them.
> * More Applications, more applications means more end users (sort of
> chicken and egg thing)
> * Swift, Possibility of integration with open source swift.  With GCC this
> is not possible.
>
> What's to lose:
> * Possibly a political issue with the FSF, but there are other projects
> which depend on languages not implemented by GCC.
> * Support for older platforms which ONLY support gcc.
>
> So, I apologize if I don't agree with the "nothing to gain" opinion.
> Yours, GC
> --
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org - http://heronsperch.blogspot.com
> http://ind.ie/phoenix/
>


-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Re: Which ObjC2.0 features are missing in the latest GCC?

[Gregory Casamento]

Yavor,


On Fri, Nov 22, 2019 at 3:01 PM Yavor Doganov  wrote:

> [ Posting this via NNTP, hope it works. ]
>
> Ivan Vučica wrote:
> > Distro packagers should also voice their opinion on whether they can
> > switch to Clang (and, hopefully, libobjc2), which I'd invite them to
> > do no matter what the decision is on presence of Clang-dependent
> > code in GNUstep core libs.
>
> I guess distro packagers who prefer Clang (or have no reasonable
> choice as that is the default and perhaps the only compiler on their
> distro) have made their choice already.
>
> Regarding Debian, I would like to point out that I cannot speak for
> them.  I am neither a Debian Developer nor a Debian Maintainer.  I
> also cannot speak for the Debian GNUstep team as I don't hold any
> special position there.
>
> But I'll have to repeat what I've said several times to fellow team
> members and other people asking me the question "Why Debian's GNUstep
> doesn't switch to Clang?".  The answer is simple: because there's a
> lot to lose and nothing to gain.
>

This is patently incorrect.  The gain is time and compatibility with the
latest code base.   I laid out the advantages and disadvantages of this in
my previous posting.  I entail you to look that post up, but I will put
what I think the losses and the gains are here for your convenience:

Switching to clang...
What's to gain:
* Time, time spent doing things the compiler can do automatically is a
waste of time and, more importantly, time NOT spent on fixing or working on
the CORE problems.
* Compatibility, much of the API is moving towards using blocks. Blocks
*ARE NOT SUPPORTED* on GCC and aren't likely to be anytime in the near
future.
* Developers, gaining developer interest means more applications.
Supporting an up to date version of the language which is in line with
developer expectations helps to attract them.
* More Applications, more applications means more end users (sort of
chicken and egg thing)
* Swift, Possibility of integration with open source swift.  With GCC this
is not possible.

What's to lose:
* Possibly a political issue with the FSF, but there are other projects
which depend on languages not implemented by GCC.
* Support for older platforms which ONLY support gcc.

So, I apologize if I don't agree with the "nothing to gain" opinion.
Yours, GC
-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Re: Which ObjC2.0 features are missing in the latest GCC?

[Maxthon Chan]

If we have Swift interworking we can also do the inverse: support Apple’s Swift 
compiler with our own C and Objective-C based libobjc2, CoreFoundation and 
Foundation packages. This way instead of throwing out chunks of the code we 
have to extend and adapt them to fit the Swift compiler. This will require us 
submit some patches to Apple though to enable building of the macOS Swift 
interworking code on the Linux version.

> On Nov 24, 2019, at 9:25 PM, Fred Kiefer  wrote:
> 
> 
> 
>> Am 24.11.2019 um 10:11 schrieb Max Chan :
>> 
>> I would like to add another plus for dropping GCC: if we want any hope for 
>> Swift interworking, we have to use clang as the compiler.
>> 
>> Apple have no plan to provide any GUI support on Linux version of Swift. If 
>> we have Swift interworking, even though we may have to drop our own libobjc, 
>> Foundation and CoreFoundation in favor of Apple’s release, the GNUStep GUI 
>> package can provide the replacement AppKit that Apple’s Swift release lacked.
> 
> This is an interesting plan, but one not shared by many GNUstep developers. 
> For me it is fine if you set up a Foundation replacement that is based on 
> Apples CoreFoundation code and I am even willing to help you to get GNUstep 
> gui working with this setup, but I would never contribute myself to this 
> development and don’t see it as part of GNUstep. You see, GNUstep as a 
> community is a very broad concept. Some of us are willing to work on a 
> desktop environment others are into obscure hardware support. But the base of 
> GNUstep are the libraries that allow writing or porting ObjC applications in 
> a completely free environment. The direction you are heading for is in my 
> view outside of that scope.
> 
> 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Johannes Brakensiek]

Am 24.11.19 um 20:08 schrieb Bertrand Dekoninck:

> Just my two pence here : I’ve got a gcc compatible branch of rik (which I 
> maintain for my ppc computers) at 
> https://github.com/BertrandDekoninck/rik.theme/tree/no_objc2
> The only thing I had to do was to remove the button animation code which uses 
> objc_setAssociatedObject.

Thank you, that's good to know. To be true: Rik.theme won't compile
using the 2.0 runtime as well. I think it accesses private ivars which
is not allowed using the new ABI. But I don't know how to work around
this yet.

Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?

[Bertrand Dekoninck]

> Le 24 nov. 2019 à 02:24, Yavor Doganov  a écrit :
> 
> Ivan Vučica wrote:
> 
>> - ARC is one.
>> - Blocks is another.
>> - @123 syntax for NSNumber (and similar stuff for arrays and dicts and
>> more) is another.
>> - Improved @property support is yet another.
> 
> This is like offering rocket fuel to someone who has a car with a
> diesel engine.  None of the packages in Debian is using these
> features, which is why I said there's nothing to win.  There's a queue
> of software packages we intend to package in Debian but neither of
> them depends on these things -- except probably the Rik theme and
> NEXTSPACE (which are not suitable for packaging for other reasons).

Just my two pence here : I’ve got a gcc compatible branch of rik (which I 
maintain for my ppc computers) at 
https://github.com/BertrandDekoninck/rik.theme/tree/no_objc2
The only thing I had to do was to remove the button animation code which uses 
objc_setAssociatedObject.
Bertrand

Re: Which ObjC2.0 features are missing in the latest GCC?

[Johannes Brakensiek]

On 24 Nov 2019, at 14:16, Yavor Doganov wrote:


Packaging libraries and development tools just because they are cool
and it is expected that hordes of developers will write useful
programs that utilize them is not a useful activity -- you have to
justify their inclusion in the distro and a hypothetical future
benefit is not a good argument.


Well, I think different about this (otherwise Apple f.e. would never 
have shipped any new software I think), but we can agree to disagree 
here.



If you don’t provide new tools for developers they are not going to
build new software for their users. It’s this way around not the
other and it’s no dilemma at all.



So you are basically saying that just because Debian does not provide
the right tools there is no software written yet?  Sorry to say that
but it's a ridiculous statement.


Well, I’m ok with that. They call me Mr. Ridiculous at times. And of 
course it is not because of Debian. It is a GNUstep and 
distribution/packaging thing.


Let me just tell you some things I did and let’s see what sounds that 
ridiculous to you:


Under Debian I typed apt-get install kdevelop and was provided a nice 
IDE and quite up-to-date tools to write and compile KDE/Qt software.


Somewhat later I typed apt-get install gnome-builder and I was provided 
a quite nice IDE and quite up-to-date tools to write and compile 
Gnome/GTK+ software.


I also typed apt-get install gnustep-devel and I was provided an IDE 
that looked like it jumped out of the 90s. I thought: Oh, not that bad, 
I can use Xcode and compile then. But I could not because the tools 
installed were not able to compile f.e. Rik.theme or .m files using 
recent language features.


I still liked the idea of GNUstep and luckily there were some nice 
people like Andreas Fink and Patryk Laurent who provided me their build 
instructions and scripts to help me building the new runtime. As a 
newbie it took me several weeks of my spare time and some mails to get a 
working build environment before I could start with developing at all. 
There were no public available build instructions or build scripts for 
Debian that worked at that time (I changed that).


Later this year I recognized that a working build environment is of no 
use at all if nobody is distributing that environment to my users. That 
was when I decided to leave Debian und use Ubuntu, because for users it 
would be way easier to install a PPA (that I could create) than to add 
an extra deb repository. Luckily some work was already done on 
https://launchpad.net/gnustep by Thomas Karl Pietrowski.


So, please tell me which part of this story sounds most ridiculous to 
you?




For me this cause is indeed a decision whether you are most
comfortable with the state in which GNUstep currently is or if you
would be more comfortable when it would develop to a further state,
maybe one where most ObjC currently is. If you want it to develop the
decision should be simple.



This is a bogus argument, GNUstep supports these new features and
developers who want to use them can do so.  Debian cannot stop them.


That’s true. It takes some efforts though. I think that’s a pity.




- https://github.com/64characters/Telephone
- https://github.com/subethaedit/SubEthaEdit
- http://colloquy.info/
- https://github.com/rburgst/time-tracker-mac



Are these projects directly buildable/runnable with GNUstep configured
for Clang and the modern runtime?  I doubt it.


No, of course they are not. But they could some day if the GNUstep 
project would decide and be able to develop some way further. That’s 
my point.


Johannes

Re: Which ObjC2.0 features are missing in the latest GCC?

[Fred Kiefer]

> Am 24.11.2019 um 10:11 schrieb Max Chan :
> 
> I would like to add another plus for dropping GCC: if we want any hope for 
> Swift interworking, we have to use clang as the compiler.
> 
> Apple have no plan to provide any GUI support on Linux version of Swift. If 
> we have Swift interworking, even though we may have to drop our own libobjc, 
> Foundation and CoreFoundation in favor of Apple’s release, the GNUStep GUI 
> package can provide the replacement AppKit that Apple’s Swift release lacked.

This is an interesting plan, but one not shared by many GNUstep developers. For 
me it is fine if you set up a Foundation replacement that is based on Apples 
CoreFoundation code and I am even willing to help you to get GNUstep gui 
working with this setup, but I would never contribute myself to this 
development and don’t see it as part of GNUstep. You see, GNUstep as a 
community is a very broad concept. Some of us are willing to work on a desktop 
environment others are into obscure hardware support. But the base of GNUstep 
are the libraries that allow writing or porting ObjC applications in a 
completely free environment. The direction you are heading for is in my view 
outside of that scope.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Johannes Brakensiek wrote:
> would it be possible to somehow ship a clang runtime on Debian or
> isn’t it? If it is how could it be achieved?

It is possible but not as an option/alternative.  Either the whole
GNUstep stack moves to Clang + the new runtime or it stays with GCC +
the GCC runtime.

To achieve the former, a preliminary discussion with the release team
must be held, to sound their opinion about dropping architectures for
about 85 packages, the transition plan and the way to solve the
inevitable file conflict between libobjc4 (the GCC runtime) and
for example libobjc2-4 (the new runtime).  That's where the GCC
maintainers' opinion should be taken into account.

I guess the release team won't have any objection to dropping
unofficial architectures but if s390x/ppc64el/mips* have to be dropped
as well there could be a problem.

Then a transition should be carried out, fixing all the bugs and
dealing with all the issues that will arise, both for the core
libraries and the reverse dependencies.

Oh, and a decent rationale for the switch must be provided.  If none
of the present packages will benefit from the switch, it is hard to
justify it.

> It seems to me you are making this a „the egg or the chicken“
> problem, which it isn’t.

Yes it is.  Libraries and development tools are building blocks that
help developers to write programs.  If a program is useful and worth
packaging, a Debian maintainer starts by packaging the tools and
libraries it needs and then by packaging the program itself.

Packaging libraries and development tools just because they are cool
and it is expected that hordes of developers will write useful
programs that utilize them is not a useful activity -- you have to
justify their inclusion in the distro and a hypothetical future
benefit is not a good argument.

> If you don’t provide new tools for developers they are not going to
> build new software for their users. It’s this way around not the
> other and it’s no dilemma at all.

So you are basically saying that just because Debian does not provide
the right tools there is no software written yet?  Sorry to say that
but it's a ridiculous statement.

> For me this cause is indeed a decision whether you are most
> comfortable with the state in which GNUstep currently is or if you
> would be more comfortable when it would develop to a further state,
> maybe one where most ObjC currently is. If you want it to develop the
> decision should be simple.

This is a bogus argument, GNUstep supports these new features and
developers who want to use them can do so.  Debian cannot stop them.

> Just one last thing to add: Cocoa/Mac software development is not
> the same as proprietary software development.

No, but free Cocoa software is in the same position as the "Java Trap"
back when Java was proprietary.  Here GNUstep comes to the rescue, but
very few of their developers value freedom.  They just want to get
their app on some store and that's it.

> - https://github.com/64characters/Telephone
> - https://github.com/subethaedit/SubEthaEdit
> - http://colloquy.info/
> - https://github.com/rburgst/time-tracker-mac

Are these projects directly buildable/runnable with GNUstep configured
for Clang and the modern runtime?  I doubt it.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Fred Kiefer]

> Am 24.11.2019 um 11:36 schrieb Johannes Brakensiek :
> 
> On 24 Nov 2019, at 10:11, Max Chan wrote:
> 
> I would like to add another plus for dropping GCC: if we want any hope for 
> Swift interworking, we have to use clang as the compiler.
> 
> Apple have no plan to provide any GUI support on Linux version of Swift. If 
> we have Swift interworking, even though we may have to drop our own libobjc, 
> Foundation and CoreFoundation in favor of Apple’s release, the GNUStep GUI 
> package can provide the replacement AppKit that Apple’s Swift release lacked.
> 
> I don’t know anything about Swift and it’s not AppKit, but maybe you already 
> recognized there now is:
> 
>   • https://github.com/Cosmo/OpenSwiftUI
>   • https://github.com/SwiftWebUI/SwiftWebUI

Nice projects, thank you for the links. SwiftWebUI is by Helge Hess and old 
friend of GNUstep. The last thing I heard from him was that he joined Apple. 
Looks like he is now back in Germany.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Maxthon Chan]

> On Nov 24, 2019, at 7:27 PM, Andreas Fink  wrote:
> 
> 
> 
>> On 24 Nov 2019, at 10:11, Max Chan  wrote:
>> 
>> I would like to add another plus for dropping GCC: if we want any hope for 
>> Swift interworking, we have to use clang as the compiler.
>> 
>> Apple have no plan to provide any GUI support on Linux version of Swift.
> 
> Theres some folks out there working on SwiftUI for other platforms as far as 
> I know.

But none working on AppKit. My point is that GNUstep GUI can provide the AppKit 
part on top of Apple’s Swift release over Swift interworking.

> Is this really true? Interoperability with Swift in my eyes is important for 
> the future

It depends on Swift interworking, and we have to refactor GUI so it uses only 
public Foundation API. Doing this means we also have to extend Apple’s 
Foundation (likely a fork) so it covers all the features omitted in the 
official release using our own GNUstep Base code, either via interworking, or 
by us rewriting it into Swift code.

I am also not a fan of Swift and prefer to stick to Objective-C with ARC for my 
projects. I have a few projects that depends pretty heavily on Objective-C 
runtime introspection, none of which works well with Swift as those are 
implemented using NSProxy semantics.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Andreas Fink]

> On 24 Nov 2019, at 10:11, Max Chan  wrote:
> 
> I would like to add another plus for dropping GCC: if we want any hope for 
> Swift interworking, we have to use clang as the compiler.
> 
> Apple have no plan to provide any GUI support on Linux version of Swift.

Theres some folks out there working on SwiftUI for other platforms as far as I 
know.

> If we have Swift interworking, even though we may have to drop our own 
> libobjc, Foundation and CoreFoundation in favor of Apple’s release, the 
> GNUStep GUI package can provide the replacement AppKit that Apple’s Swift 
> release lacked.

Is this really true? Interoperability with Swift in my eyes is important for 
the future

Even though I personally don't like Swift (mainly because its not a natural 
upgrade path from C style but implies totally new syntax and does not mean you 
can easily slam existing C or ObjectiveC code in it and it takes time I don't 
have to learn it again), its a modern language getting more and more 
importance. Also in the light of the strong support of Swift from IBM I would 
not underestimate its potential.

The future of Gnustep I see in the area of providing a real good desktop at the 
end. It doesn't have to be a copycat of OS X but allowing ported applications 
to work more or less out of the box. I like what ElementaryOS does. Except its 
based on some fancy language called Vala which is a showstopper for porting. 
The strengths of Gnustep are that people writing MacOS X apps could port them 
to other platforms. And that should include Swift apps  as this area its 
growing big. (and as Swift nicely interwork with ObjC).

I'm  happy to contribute (except I'm not a GUI guy but more  network/daemons 
focused).

Re: Which ObjC2.0 features are missing in the latest GCC?

[Maxthon Chan]

Those are not the AppKit replacement I was talking about. I was talking about 
the Cocoa component AppKit, which GNUstep GUI implements. OpenSwiftUI 
implemented the newer SwiftUI API, while SwiftWebUI is a Web development kit.

> On Nov 24, 2019, at 6:36 PM, Johannes Brakensiek  
> wrote:
> 
> On 24 Nov 2019, at 10:11, Max Chan wrote:
> 
> I would like to add another plus for dropping GCC: if we want any hope for 
> Swift interworking, we have to use clang as the compiler.
> 
> Apple have no plan to provide any GUI support on Linux version of Swift. If 
> we have Swift interworking, even though we may have to drop our own libobjc, 
> Foundation and CoreFoundation in favor of Apple’s release, the GNUStep GUI 
> package can provide the replacement AppKit that Apple’s Swift release lacked.
> 
> I don’t know anything about Swift and it’s not AppKit, but maybe you already 
> recognized there now is:
> 
> https://github.com/Cosmo/OpenSwiftUI 
> https://github.com/SwiftWebUI/SwiftWebUI 
> 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Johannes Brakensiek]

On 24 Nov 2019, at 10:11, Max Chan wrote:

I would like to add another plus for dropping GCC: if we want any hope 
for Swift interworking, we have to use clang as the compiler.


Apple have no plan to provide any GUI support on Linux version of 
Swift. If we have Swift interworking, even though we may have to drop 
our own libobjc, Foundation and CoreFoundation in favor of Apple’s 
release, the GNUStep GUI package can provide the replacement AppKit 
that Apple’s Swift release lacked.


I don’t know anything about Swift and it’s not AppKit, but maybe you 
already recognized there now is:


- https://github.com/Cosmo/OpenSwiftUI
- https://github.com/SwiftWebUI/SwiftWebUI

Re: Which ObjC2.0 features are missing in the latest GCC?

[Max Chan]

I would like to add another plus for dropping GCC: if we want any hope for 
Swift interworking, we have to use clang as the compiler.

Apple have no plan to provide any GUI support on Linux version of Swift. If we 
have Swift interworking, even though we may have to drop our own libobjc, 
Foundation and CoreFoundation in favor of Apple’s release, the GNUStep GUI 
package can provide the replacement AppKit that Apple’s Swift release lacked.

顺颂商祺
陈北宗 Max Chan, from SushiBits Projects
Tel. +86 186-2165-8748
https://github.com/SushiBits

> On Nov 24, 2019, at 15:21, Johannes Brakensiek  
> wrote:
> 
> 
> On 24 Nov 2019, at 2:24, Yavor Doganov wrote:
> 
> Ivan Vučica wrote:
> 
> On Fri, Nov 22, 2019 at 8:02 PM Yavor Doganov  wrote:
> 
> The answer is simple: because there's a lot to lose and nothing to
> gain.
> 
> This is unfortunately wrong. There is a lot to gain.
> 
> Right or wrong depends on the point of view, which ultimtately boils
> down to one's values and beliefs. What is gain for some may be loss
> for others. It appears we have different values, hence the
> discrepancy.
> 
> Developers who want to start using Debian-built GNUstep libraries
> can start using tons and tons of features that GCC and GCC runtime
> do not support.
> 
> Developers who want to start using these new (not so new -- 10 years
> old!) features have the option to build the environment they need on
> top of Debian (if that is their distro of choice) or switch to another
> distro that provides prebuilt packages.
> 
> But that is the wrong answer.
> 
> You, developers, tend to forget that free software is for users.
> Developers are users too in a broad sense but they are a very small
> part of the whole mass of people using a particular piece of software.
> If these fancy features existed for 10 years, why they have not
> inclined developers to write more free software that is relying on
> them? Surely that's not because Debian stopped them? Or because the
> GNUstep project is stopping them?
> 
> My task as a free software contributor (with the extremely limited
> skills I have) is to help achieve the goals of the Free Software
> Movement. Providing "tons and tons of features" to developers who
> don't care at all about free software (at least the majority of them)
> and who won't write a single line of code for the cause I'm aligned to
> doesn't strike me as the "right" thing to do.
> 
> I don't mind helping them as a side effect of helping free software.
> In this case, however, it is all about them.
> 
> - ARC is one.
> - Blocks is another.
> - @123 syntax for NSNumber (and similar stuff for arrays and dicts and
> more) is another.
> - Improved @property support is yet another.
> 
> This is like offering rocket fuel to someone who has a car with a
> diesel engine. None of the packages in Debian is using these
> features, which is why I said there's nothing to win. There's a queue
> of software packages we intend to package in Debian but neither of
> them depends on these things -- except probably the Rik theme and
> NEXTSPACE (which are not suitable for packaging for other reasons).
> 
> Right now I'm working on a new upstream release of a package which
> uses NSNotificationCener-addObserverForName:object:queue:usingBlock:.
> This is a method which is declared and supposed to be supported even
> with GCC, I just don't know the (GCC) syntax I'm supposed to use so
> I'm experimenting with GCC nested functions as replacement. If that
> fails, I guess I'll solve it somehow, using a different approach.
> That's the first case I face ever -- I've seen methods using blocks in
> upstream code before but they were no-op anyway as there was no
> GNUstep implementation. On the contrary, there are tons of
> block-unrelated things which are not implemented, especially in GUI.
> 
> The biggest hurdle with porting apps IMVHO is missing functionality
> and dependency on Core* stuff and other libraries with no free
> implementation. The switch to Clang is not going to solve these
> problems. The only thing it solves is making the life of developers
> of properiatary software easy. That is not my goal.
> 
> But I'd say that Debian's packaging of GNUstep is very important and
> even if the core doesn't start depending on these features, they
> should be made available.
> 
> I don't know why Debian is important, but they cannot be made
> available as an option. It would mean duplicate packages with
> different names -- the release team will not allow it and the
> ftpmasters will not allow it.
> 
> You probably weren't around when we (GNUstep people in Debian) had to
> scrap and fight to prevent it from being removed. GNUstep in Debian
> back then was undermaintained and violated the FHS, it was also full
> of bugs (that is, obvious bugs such as frequent failures to build from
> source) and blatant bugs solely due to packaging. Hubert wrote a tool
> to FHS-ify most of the packages, we fixed most bugs and we had a
> helping hand from the Debian 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Johannes Brakensiek]

On 24 Nov 2019, at 2:24, Yavor Doganov wrote:


Ivan Vučica wrote:

On Fri, Nov 22, 2019 at 8:02 PM Yavor Doganov  wrote:

The answer is simple: because there's a lot to lose and nothing to
gain.



This is unfortunately wrong. There is a lot to gain.


Right or wrong depends on the point of view, which ultimtately boils
down to one's values and beliefs.  What is gain for some may be loss
for others.  It appears we have different values, hence the
discrepancy.


Developers who want to start using Debian-built GNUstep libraries
can start using tons and tons of features that GCC and GCC runtime
do not support.


Developers who want to start using these new (not so new -- 10 years
old!) features have the option to build the environment they need on
top of Debian (if that is their distro of choice) or switch to another
distro that provides prebuilt packages.

But that is the wrong answer.

You, developers, tend to forget that free software is for users.
Developers are users too in a broad sense but they are a very small
part of the whole mass of people using a particular piece of software.
If these fancy features existed for 10 years, why they have not
inclined developers to write more free software that is relying on
them?  Surely that's not because Debian stopped them?  Or because the
GNUstep project is stopping them?

My task as a free software contributor (with the extremely limited
skills I have) is to help achieve the goals of the Free Software
Movement.  Providing "tons and tons of features" to developers who
don't care at all about free software (at least the majority of them)
and who won't write a single line of code for the cause I'm aligned to
doesn't strike me as the "right" thing to do.

I don't mind helping them as a side effect of helping free software.
In this case, however, it is all about them.


- ARC is one.
- Blocks is another.
- @123 syntax for NSNumber (and similar stuff for arrays and dicts 
and

more) is another.
- Improved @property support is yet another.


This is like offering rocket fuel to someone who has a car with a
diesel engine.  None of the packages in Debian is using these
features, which is why I said there's nothing to win.  There's a queue
of software packages we intend to package in Debian but neither of
them depends on these things -- except probably the Rik theme and
NEXTSPACE (which are not suitable for packaging for other reasons).

Right now I'm working on a new upstream release of a package which
uses NSNotificationCener-addObserverForName:object:queue:usingBlock:.
This is a method which is declared and supposed to be supported even
with GCC, I just don't know the (GCC) syntax I'm supposed to use so
I'm experimenting with GCC nested functions as replacement.  If that
fails, I guess I'll solve it somehow, using a different approach.
That's the first case I face ever -- I've seen methods using blocks in
upstream code before but they were no-op anyway as there was no
GNUstep implementation.  On the contrary, there are tons of
block-unrelated things which are not implemented, especially in GUI.

The biggest hurdle with porting apps IMVHO is missing functionality
and dependency on Core* stuff and other libraries with no free
implementation.  The switch to Clang is not going to solve these
problems.  The only thing it solves is making the life of developers
of properiatary software easy.  That is not my goal.


But I'd say that Debian's packaging of GNUstep is very important and
even if the core doesn't start depending on these features, they
should be made available.


I don't know why Debian is important, but they cannot be made
available as an option.  It would mean duplicate packages with
different names -- the release team will not allow it and the
ftpmasters will not allow it.

You probably weren't around when we (GNUstep people in Debian) had to
scrap and fight to prevent it from being removed.  GNUstep in Debian
back then was undermaintained and violated the FHS, it was also full
of bugs (that is, obvious bugs such as frequent failures to build from
source) and blatant bugs solely due to packaging.  Hubert wrote a tool
to FHS-ify most of the packages, we fixed most bugs and we had a
helping hand from the Debian GCC maintainers who said it would be very
worthwile to keep GNUstep in Debian, at least as a testing ground for
GCC.

And that's what it's been, more or less; GNUstep had a rapid decline
in the user base some years ago and it appears it is not going to
recover.  All the Clangs in the world are not going to help you with
that.  But in your quest for popularity you may lose some of the solid
foundations that are still keeping this project afloat.

What's lost is builds on some architectures. Can't those 
architectures

keep using GCC-targeting libraries or be actively disabled?


No.  Packages which no longer build for a particular architecture must
be removed manually by the ftpmasters, after a request is filed.  If
the architecture is official 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

Ivan Vučica wrote:
> On Fri, Nov 22, 2019 at 8:02 PM Yavor Doganov  wrote:
> > The answer is simple: because there's a lot to lose and nothing to
> > gain.

> This is unfortunately wrong. There is a lot to gain.

Right or wrong depends on the point of view, which ultimtately boils
down to one's values and beliefs.  What is gain for some may be loss
for others.  It appears we have different values, hence the
discrepancy.

> Developers who want to start using Debian-built GNUstep libraries
> can start using tons and tons of features that GCC and GCC runtime
> do not support.

Developers who want to start using these new (not so new -- 10 years
old!) features have the option to build the environment they need on
top of Debian (if that is their distro of choice) or switch to another
distro that provides prebuilt packages.

But that is the wrong answer.

You, developers, tend to forget that free software is for users.
Developers are users too in a broad sense but they are a very small
part of the whole mass of people using a particular piece of software.
If these fancy features existed for 10 years, why they have not
inclined developers to write more free software that is relying on
them?  Surely that's not because Debian stopped them?  Or because the
GNUstep project is stopping them?

My task as a free software contributor (with the extremely limited
skills I have) is to help achieve the goals of the Free Software
Movement.  Providing "tons and tons of features" to developers who
don't care at all about free software (at least the majority of them)
and who won't write a single line of code for the cause I'm aligned to
doesn't strike me as the "right" thing to do.

I don't mind helping them as a side effect of helping free software.
In this case, however, it is all about them.

> - ARC is one.
> - Blocks is another.
> - @123 syntax for NSNumber (and similar stuff for arrays and dicts and
> more) is another.
> - Improved @property support is yet another.

This is like offering rocket fuel to someone who has a car with a
diesel engine.  None of the packages in Debian is using these
features, which is why I said there's nothing to win.  There's a queue
of software packages we intend to package in Debian but neither of
them depends on these things -- except probably the Rik theme and
NEXTSPACE (which are not suitable for packaging for other reasons).

Right now I'm working on a new upstream release of a package which
uses NSNotificationCener-addObserverForName:object:queue:usingBlock:.
This is a method which is declared and supposed to be supported even
with GCC, I just don't know the (GCC) syntax I'm supposed to use so
I'm experimenting with GCC nested functions as replacement.  If that
fails, I guess I'll solve it somehow, using a different approach.
That's the first case I face ever -- I've seen methods using blocks in
upstream code before but they were no-op anyway as there was no
GNUstep implementation.  On the contrary, there are tons of
block-unrelated things which are not implemented, especially in GUI.

The biggest hurdle with porting apps IMVHO is missing functionality
and dependency on Core* stuff and other libraries with no free
implementation.  The switch to Clang is not going to solve these
problems.  The only thing it solves is making the life of developers
of properiatary software easy.  That is not my goal.

> But I'd say that Debian's packaging of GNUstep is very important and
> even if the core doesn't start depending on these features, they
> should be made available.

I don't know why Debian is important, but they cannot be made
available as an option.  It would mean duplicate packages with
different names -- the release team will not allow it and the
ftpmasters will not allow it.

You probably weren't around when we (GNUstep people in Debian) had to
scrap and fight to prevent it from being removed.  GNUstep in Debian
back then was undermaintained and violated the FHS, it was also full
of bugs (that is, obvious bugs such as frequent failures to build from
source) and blatant bugs solely due to packaging.  Hubert wrote a tool
to FHS-ify most of the packages, we fixed most bugs and we had a
helping hand from the Debian GCC maintainers who said it would be very
worthwile to keep GNUstep in Debian, at least as a testing ground for
GCC.

And that's what it's been, more or less; GNUstep had a rapid decline
in the user base some years ago and it appears it is not going to
recover.  All the Clangs in the world are not going to help you with
that.  But in your quest for popularity you may lose some of the solid
foundations that are still keeping this project afloat.

> What's lost is builds on some architectures. Can't those architectures
> keep using GCC-targeting libraries or be actively disabled?

No.  Packages which no longer build for a particular architecture must
be removed manually by the ftpmasters, after a request is filed.  If
the architecture is official (meaning it is officially supported 

Re: Which ObjC2.0 features are missing in the latest GCC?

[Ivan Vučica]

On Fri, Nov 22, 2019 at 8:02 PM Yavor Doganov  wrote:
> The answer is simple: because there's a
> lot to lose and nothing to gain.

As someone that does want to see GCC have continued support in
GNUstep's core libs, and as someone who has been happy in an ARC-free
world, and as someone that's very appreciative of work being put into
keeping GNUstep available in Debian:

This is unfortunately wrong. There is a lot to gain. Developers who
want to start using Debian-built GNUstep libraries can start using
tons and tons of features that GCC and GCC runtime do not support.
Most have been outlined throughout this thread, but here's some that
come to mind:

- ARC is one.
- Blocks is another.
- @123 syntax for NSNumber (and similar stuff for arrays and dicts and
more) is another.
- Improved @property support is yet another.

I'm not dependent on any of these. But I'd say that Debian's packaging
of GNUstep is very important and even if the core doesn't start
depending on these features, they should be made available.

What's lost is builds on some architectures. Can't those architectures
keep using GCC-targeting libraries or be actively disabled? Even if
the core and GCC support these architectures, do Debian packages have
to ship for them?

Re: Which ObjC2.0 features are missing in the latest GCC?

[Yavor Doganov]

[ Posting this via NNTP, hope it works. ]

Ivan Vučica wrote:
> Distro packagers should also voice their opinion on whether they can
> switch to Clang (and, hopefully, libobjc2), which I'd invite them to
> do no matter what the decision is on presence of Clang-dependent
> code in GNUstep core libs.

I guess distro packagers who prefer Clang (or have no reasonable
choice as that is the default and perhaps the only compiler on their
distro) have made their choice already.

Regarding Debian, I would like to point out that I cannot speak for
them.  I am neither a Debian Developer nor a Debian Maintainer.  I
also cannot speak for the Debian GNUstep team as I don't hold any
special position there.

But I'll have to repeat what I've said several times to fellow team
members and other people asking me the question "Why Debian's GNUstep
doesn't switch to Clang?".  The answer is simple: because there's a
lot to lose and nothing to gain.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Gregory Casamento]

Blocks are a bigger problem than memory management.  It is holding us back.

On Fri, Nov 22, 2019 at 12:38 PM Fred Kiefer  wrote:

> > Am 22.11.2019 um 15:44 schrieb Andreas Fink :
> >
> > The fact is that gcc can not do ARC. This is the main show stopper for
> gcc.
> > On the other hand, switching from gcc to clang is not a problem for
> "traditional programming style" programmers.
> >
> > The only problem I can see is platforms which gcc supports but clang
> does not. So the real question is are there any users who use ObjC stuff
> with GnuStep under, lets say strange embedded systems.
> > Given ObjC does not have a bright future under gcc anyway (as they have
> still not implemented ObjC 2.0 features after like 10 years it's out now),
> does mean it will only get worse.
> >
> > Besides that we have to consider that sticking to gcc will also hinders
> newcomers to get involved. And this i I think is a important point.
> > The developers hehre with 20 years+ experience will have no problem
> working around non ARC stuff and going backwords because we all know the
> old way.
> > The youngsters out there however don't. If we want to get Gnustep into
> the modern area, we will need to be attractive to newcomes and this means
> keeping up with the modern API's etc. And gcc is miserably failing here.
> Thats the main problem, not if you don't want to use ARC (which is still
> fine) or not. Others want to use ARC but can't under GCC.
> >
> > In other words, going for clang doesnt mean ObjC 1.0 code wont run but
> it means a lot of ObjC2.0 code will start to run.
>
> This is another discussion I would have preferred to stay out of. We had
> this and other similar discussions so many times before. To me it just
> seems not worthwhile to participate once more.
>
> There are many benefits that ObjC 2.0 support with clang could bring,
> still I can understand why some people prefer to stay with a compiler and a
> language they know. I myself use gcc and even with its limitations it
> allows me to do useful programming for GNUstep. And many times gcc has
> pointed to bugs in the code where clang accepted the code. (The opposite is
> also true, it really has been good for us to have two different compilers
> to inspect our code.) What I would never do is to argue for others to use
> gcc. Just use the compiler you prefer.
>
> And this is where this discussion is getting odd. It has been possible to
> use GNUstep code in ObjC 2.0 projects, thanks to the great work David has
> been doing. And if we are honest the work to support this inside of GNUstep
> wasn’t much. Just using a few macros here and there and things work. We
> could even go further and have a few more macros that allow us to specify
> the property attributes in GNUstep base and redefine the ASSIGN, RETAIN and
> RELEASE etc macros as noops and with a bit of code cleanup GNUstep base
> could be compiled with ARC. All of this should be possible while still
> keeping support for gcc. Even for simple block usage I am sure that if
> David and I set down for a weekend we could come up with a macro to define
> a callable block (probably without capturing variables and without ARC
> special cases, just the most common case). It is just that the need for
> this hasn’t come up.
>
> I really don’t see gcc support is itself holding us back. At least not
> more than the incomplete CoreFoundation, or the fact that base is not build
> on top of core base, the binary incompatible of Foundation and GNUstep base
> or the missing usage of C++ in the implementation of GNUstep. These and
> some other factors seem more important to me. But if we start to change all
> of these, the resulting project would be quite different from current
> GNUstep. And most likely we would have lost most of the current GNUstep
> developers in the transition process. Nobody can tell whether we would gain
> new active core developers through this change. I really doubt that and
> therefor would prefer not to drop gcc support. If you disagree, fine. But
> for GNUstep it would be great if you could pledge to work on the code in
> the next few years. Otherwise the project will be dying even faster than it
> is now.
>
> Fred
>
>
>

-- 
Gregory Casamento
GNUstep Lead Developer / OLC, Principal Consultant
http://www.gnustep.org - http://heronsperch.blogspot.com
http://ind.ie/phoenix/

Re: Which ObjC2.0 features are missing in the latest GCC?

[Ivan Vučica]

On Fri, Nov 22, 2019 at 2:53 PM Andreas Fink  wrote:
> In other words, going for clang doesnt mean ObjC 1.0 code wont run but it 
> means a lot of ObjC2.0 code will start to run.

The discussion is not whether ObjC2.0-and-later-unnamed-variants code
will start to run (because it already runs), the question is whether
core libs (Foundation, GUI and Back) should require ObjC2.0-and-later.

At this time, it's #ifdef'able and/or runtime-detectable.

If we drop GCC, we can forgo #ifdefs and other workarounds. But we
invite complexities of things like blocks into the core codebase,
which we may or may not want.

However the decision is made, I'd vote for making a final release
before any Clang-requiring features are added. Distro packagers should
also voice their opinion on whether they can switch to Clang (and,
hopefully, libobjc2), which I'd invite them to do no matter what the
decision is on presence of Clang-dependent code in GNUstep core libs.

Explicitly +cc Yavor for visibility; I don't know off the top of my
head of package maintainers on other systems.

Re: Which ObjC2.0 features are missing in the latest GCC?

[Ivan Vučica]

On Fri 22 Nov 2019 at 17:41, Fred Kiefer  wrote:

> I really don’t see gcc support is itself holding us back. At least not
> more than the incomplete CoreFoundation, or the fact that base is not build
> on top of core base,


Or GUI on top of Core Graphics which would then have its backends... but
that’s too deep of a rabbit hole :(

the binary incompatible of Foundation and GNUstep base or the missing usage
> of C++ in the implementation of GNUstep.


Now, I see what David says about use of C++ in implementation of
Foundation... but I’d expect that putting C++ would bring the compilation
times up for everyone. Not a showstopper, but there’s something cool about
all of GNUstep being buildable really quickly (configure steps usually
taking longer than the build of the project itself).
-- 
Sent from Gmail Mobile

Re: Which ObjC2.0 features are missing in the latest GCC?

[Fred Kiefer]

> Am 22.11.2019 um 15:44 schrieb Andreas Fink :
> 
> The fact is that gcc can not do ARC. This is the main show stopper for gcc. 
> On the other hand, switching from gcc to clang is not a problem for 
> "traditional programming style" programmers.
> 
> The only problem I can see is platforms which gcc supports but clang does 
> not. So the real question is are there any users who use ObjC stuff with 
> GnuStep under, lets say strange embedded systems.
> Given ObjC does not have a bright future under gcc anyway (as they have still 
> not implemented ObjC 2.0 features after like 10 years it's out now), does 
> mean it will only get worse.
> 
> Besides that we have to consider that sticking to gcc will also hinders 
> newcomers to get involved. And this i I think is a important point.
> The developers hehre with 20 years+ experience will have no problem working 
> around non ARC stuff and going backwords because we all know the  old way.
> The youngsters out there however don't. If we want to get Gnustep into the 
> modern area, we will need to be attractive to newcomes and this means keeping 
> up with the modern API's etc. And gcc is miserably failing here. Thats the 
> main problem, not if you don't want to use ARC (which is still fine) or not. 
> Others want to use ARC but can't under GCC.
> 
> In other words, going for clang doesnt mean ObjC 1.0 code wont run but it 
> means a lot of ObjC2.0 code will start to run.

This is another discussion I would have preferred to stay out of. We had this 
and other similar discussions so many times before. To me it just seems not 
worthwhile to participate once more.

There are many benefits that ObjC 2.0 support with clang could bring, still I 
can understand why some people prefer to stay with a compiler and a language 
they know. I myself use gcc and even with its limitations it allows me to do 
useful programming for GNUstep. And many times gcc has pointed to bugs in the 
code where clang accepted the code. (The opposite is also true, it really has 
been good for us to have two different compilers to inspect our code.) What I 
would never do is to argue for others to use gcc. Just use the compiler you 
prefer.

And this is where this discussion is getting odd. It has been possible to use 
GNUstep code in ObjC 2.0 projects, thanks to the great work David has been 
doing. And if we are honest the work to support this inside of GNUstep wasn’t 
much. Just using a few macros here and there and things work. We could even go 
further and have a few more macros that allow us to specify the property 
attributes in GNUstep base and redefine the ASSIGN, RETAIN and RELEASE etc 
macros as noops and with a bit of code cleanup GNUstep base could be compiled 
with ARC. All of this should be possible while still keeping support for gcc. 
Even for simple block usage I am sure that if David and I set down for a 
weekend we could come up with a macro to define a callable block (probably 
without capturing variables and without ARC special cases, just the most common 
case). It is just that the need for this hasn’t come up.

I really don’t see gcc support is itself holding us back. At least not more 
than the incomplete CoreFoundation, or the fact that base is not build on top 
of core base, the binary incompatible of Foundation and GNUstep base or the 
missing usage of C++ in the implementation of GNUstep. These and some other 
factors seem more important to me. But if we start to change all of these, the 
resulting project would be quite different from current GNUstep. And most 
likely we would have lost most of the current GNUstep developers in the 
transition process. Nobody can tell whether we would gain new active core 
developers through this change. I really doubt that and therefor would prefer 
not to drop gcc support. If you disagree, fine. But for GNUstep it would be 
great if you could pledge to work on the code in the next few years. Otherwise 
the project will be dying even faster than it is now.

Fred

Re: Which ObjC2.0 features are missing in the latest GCC?

[H. Nikolaus Schaller]

> Am 22.11.2019 um 17:47 schrieb David Wetzel :
> 
> Andreas is very right here.
> 
> Von meinem iPhone gesendet
> 
>> Am 22.11.2019 um 09:53 schrieb Andreas Fink :
>> 
>> The developers hehre with 20 years+ experience will have no problem working 
>> around non ARC stuff and going backwords because we all know the  old way.
>> The youngsters out there however don't. If we want to get Gnustep into the 
>> modern area, we will need to be attractive to newcomes and this means 
>> keeping up with the modern API's etc. And gcc is miserably failing here.

That is why I propose a translator that can translate ARC ObjC 2.0 to ObjC 1.0 
which allows to be more independent of the compiler...
In earlier times there was a similar approach (POC?) to translate ObjC 1.0 to 
Standard C.

Re: Which ObjC2.0 features are missing in the latest GCC?

[David Wetzel]

Andreas is very right here.

Von meinem iPhone gesendet

> Am 22.11.2019 um 09:53 schrieb Andreas Fink :
> 
> The developers hehre with 20 years+ experience will have no problem working 
> around non ARC stuff and going backwords because we all know the  old way.
> The youngsters out there however don't. If we want to get Gnustep into the 
> modern area, we will need to be attractive to newcomes and this means keeping 
> up with the modern API's etc. And gcc is miserably failing here.

Re: Which ObjC2.0 features are missing in the latest GCC?

[lars.sonchocky-helld...@hamburg.de]

> Am 22.11.2019 um 15:44 schrieb Andreas Fink :
> 
> 
>> 
>>> This is a major advantage of Objc2.0. 
>>> I must admit it took me a while to get used to though. But at the end it 
>>> paid off a lot.
>> 
>> Well, to be precise: ARC could also be done with ObjC 1.0 as far as I see. 
>> There is IMHO no special syntax for ARC. You just remove all 
>> retain/release/autorelease from the code and the compiler is clever enough 
>> to magically make it still work.
>> 
>> So in summary, ARC alone isn't sufficiently helpful for my work to switch to 
>> ObjC 2.0 and no longer use gcc.
>> 
> 
> 
> The fact is that gcc can not do ARC. This is the main show stopper for gcc. 
> On the other hand, switching from gcc to clang is not a problem for 
> "traditional programming style" programmers.
> 
> The only problem I can see is platforms which gcc supports but clang does 
> not. So the real question is are there any users who use ObjC stuff with 
> GnuStep under, lets say strange embedded systems.
> Given ObjC does not have a bright future under gcc anyway (as they have still 
> not implemented ObjC 2.0 features after like 10 years it's out now), does 
> mean it will only get worse.
> 
> Besides that we have to consider that sticking to gcc will also hinders 
> newcomers to get involved. And this i I think is a important point.
> The developers hehre with 20 years+ experience will have no problem working 
> around non ARC stuff and going backwords because we all know the  old way.
> The youngsters out there however don't. If we want to get Gnustep into the 
> modern area, we will need to be attractive to newcomes and this means keeping 
> up with the modern API's etc. And gcc is miserably failing here. Thats the 
> main problem, not if you don't want to use ARC (which is still fine) or not. 
> Others want to use ARC but can't under GCC.
> 
> In other words, going for clang doesnt mean ObjC 1.0 code wont run but it 
> means a lot of ObjC2.0 code will start to run.
> 

I think the main problem here is that Nikolaus (and Riccardo) are using 
platforms where there isn’t even a recent GCC available (IIRC Riccardo called 
some time ago for keeping GCC 2.95 support — surely not for the pure fun of 
supporting such old compilers). So even fixing GCC by adding ObjC 2.0 support 
won’t satisfy some. What could be done about this? I have no idea …

regards,

Lars

Re: Which ObjC2.0 features are missing in the latest GCC?

[Jordan Schidlowsky]

> On Nov 22, 2019, at 2:08 AM, H. Nikolaus Schaller  wrote:
> 
>> I find it incredibly hard to understand why someone would actively choose to 
>> have to spend more time thinking about memory management so that they can 
>> end up with larger binaries that run more slowly.
> 
> Because it is less time typing release or autorelease at the right plcae, 
> than finding out how to install new toolchains which have unexpected 
> dependencies like search paths and choosing between multiple runtime libs...

I think this answer speaks volumes.  It's not a language thing, it's a tooling 
one...  Which is even more reason to focus on one toolchain to keep things 
simple and organized.  And the fact that Clang is a cross-compiler by default 
is a huge win IMHO.