Re: Embedded blocks...

[Riccardo Mottola]

Hi,

Yavor Doganov wrote:
> В Tue, 29 Oct 2019 12:50:23 +0000, David Chisnall написа:
> > I don't really understand how this works. GCC does not support a
> > post-2005 dialect of Objective-C.  GNUstep is a framework that aims to
> > provide an implementation of the 2019 Objective-C standard library.  Why
> > is it politically problematic for GNUstep to drop support for GCC, but
> > not problematic for GCC to drop support for GNUstep?
> But GCC didn't drop support for GNUstep.  It just cannot cope with the
> changes of the language/runtime that are completely under the control
> of a single corporation.  It is not surprising that the last major
> changes in GCC related to Objective-C were implemented by GNUstep
> developers (Nicola and Richard, IIRC).

I would hate to be dependent on clang. I actually like the situation 
where we have two compilers. On many OS/arch combinations I use... one 
compiler is better than the other. I like this freedom.
GNU-step GNU-compiler for me is a good match, but being able to use 
clang is a good add, the other way, I don't feel comfortable.


> > Basically, the only target market is GNUstep developers on platforms
> > that Clang doesn't support, which I think is a set containing only
> > Riccardo).
> This is an exaggeration.  I fixed a bug in SOPE on SuperH just a few
> months ago.  Over the years, I recall fixes in GNUstep core libraries
> on HP-PA, GNU/Hurd and GNU/kFreeBSD, to name a few.  And non-core
> packages on sparc, ppc, ppc64, powerpcspe and m68k.  GNUstep aims for
> portability and this is closely related with code quality.  Once you
> start dropping targets for no good reason you can expect regressions
> in quality here and there, and more effort when the need to support a
> new architecture arises.

I subscribe to this.
Thank you for stepping in, or it looks like me being "the only one" 
which is not true.
I happen to be the only one writing actively to this group and being 
member of the core team, but there are others which just are "silent".

I don't use GNUstep on m68k since years.. because I was unable to 
upgrade my machine to a more recent debian, font memories :-P

However my interest in PPC revived a lot since I am member of the PPC 
(Power Progress Community) and GCC is currently a better compiler for 
that platform.
On SPARC the same (to be honest, I didn't even try clang there yet)

I still need to play on MIPS LE.. and will test compilers there. 
Availability of these boards has risen the multitude of platforms again, 
exciting.

> В Wed, 30 Oct 2019 01:27:56 +0200, Sergii Stoian написа:
> > IMHO political motifs shouldn’t constrain technical decisions
> Well, the goal of the GNU Project is technical but that goal is set
> because of an ideal and GNU maintainers are supposed to exercise
> proper judgment when making decisions on technical matters, too.

Well... this could be discussed, the whole GNU project can be said 
"political" (see quotes) if not at least ideological.
Several projects and libraries were formed just because one didn't a 
specific license.
One could say that the whole Free Software is born out of "politcal 
reasons."


> > Moreover using these nice Objective-C 2.0 features make GNUstep code
> > look much more familiar to potential macOS/iOS developers.
> It is extremely naive to expect that macOS/iOS developers will start
> coming in numbers, anxious to implement classes and missing
> functionality, just because of that.  GNUstep predates the thing
> called "Objective-C 2.0" and I don't remember an avalanche of patches
> flowing in before 2005.

They won't... the cool thing is Swift anyway... or Rust or whatever if 
you like chaning language every day. But some occasional MacOS dev could 
peek by.
I like the cleanieness of Obj-C 1.0 except some compromises it had.

> (Likewise, it was foolish to presume that the move to GitHub will
> install an entire new generation of energetic programmers.  The
> reality is that pretty much the same small set of heroic people are
> doing the work.)

Here, even if I don't like GitHub, I must say that it helps in exposure, 
the code is easier to browse and even if a hoard of programmers won't 
materialize because GNUstep's appeal is a niche, we can get more report 
and exposure. Here a can of worm opens about the bad interface of code 
comments or comments on patches of GitHub opens.
So... I don't like the "tool" but the fact that it is of ease is true.
I myself have contributed easily wth code and patches to other project 
just because their "home" was consistent and easy. GitHub or equivalent 
gitlab environment make that easy. Having two bug trackers, a code in 
another place and releases in yet another... do not help.
Not a real issue, mind you, but don't help for sure.

Riccardo