Re: Embedded blocks...

[Sergii Stoian]

On Oct 29, 2019, at 15:43, David Chisnall  wrote:

> On 29/10/2019 13:18, Ivan Vučica wrote:
>> Naive question: What’s the problem #ifdefing out the code that depends on 
>> blocks when building on gcc?
> 
> Locally?  Not much.  It means that anyone using clang and a GCC-built GNUstep 
> will have some surprises, but they probably will anyway because the GCC code 
> will support the (very) old ABI and not be useable with modern Objective-C 
> anyway.
> 
> Globally?  It means that we can't take advantage of things like ARC and 
> blocks usefully across GNUstep.  Both have significant developer productivity 
> wins, as does Objective-C++ (which mostly works with recent GCC, but still 
> has some quite rough edges).  If we have loads of developers with ample time 
> and aren't worried about the fact that it's hard to recruit new Objective-C 
> programmers when we force them to use a decade-old version of the language, 
> then that's not an issue either.
> 
> I haven't done much Objective-C recently, but the last time I did I found 
> that I could write about a quarter of the code in Objective-C++[1] with ARC 
> than I'd had to write in Objective-C with retain / release (and got smaller 
> and faster binaries).  After that experience, there's no way that I'd go back 
> to writing the kind of code that GNUstep requires.
> 
> David
> 
> [1] I have a small set of helpers that improve interop:
> 
> - C++ wrappers for -hash, -compare: and -isEqual: that let me use Objective-C 
> objects in C++ collections.
> 
> - A get<> template that calls a -{foo}Value method based on the type (e.g. 
> get(id x) -> [x intValue]).  This allows me to write other C++ templates 
> that convert Objective-C objects to other types usefully.
> 
> - Wrappers for NSString and NSIndexSet that use the native range accessors to 
> implement C++ iterators, so these can be used with range-based for loops 
> (e.g. for (NSUInteger i : {some NSIndexSet}).
> 
> - An RIAA wrapper for posting KVO notifications.  Posts the will-change 
> notification on construction and the did-change notification on destruction, 
> so I never accidentally fail to send one of the pair.
> 
> I also make heavy use of a number of Objective-C features that GCC doesn't 
> support:
> 
> - Generics (type erasing, but they catch simple compile-time type errors).
> 
> - Array and dictionary literals.
> 
> - Blocks
> 
> - ARC
> 
> - Private ivar definitions in the @implementation context.
> 
> All of these either improve my productivity, increase the quality of the 
> code, or both.
> 

I absolutely agree with you, David. 
IMHO political motifs shouldn’t constrain technical decisions (besides licence, 
of course).
Moreover using these nice Objective-C 2.0 features make GNUstep code look much 
more familiar to potential macOS/iOS developers.

Sergii

Re: Embedded blocks...

[Ivan Vučica]

Naive question: What’s the problem #ifdefing out the code that depends on
blocks when building on gcc?

On Tue 29 Oct 2019 at 12:51, David Chisnall 
wrote:

> On 27/10/2019 16:05, Gregory Casamento wrote:
> > We are a GNU / FSF project.  Dropping support for GCC would be bad
> > political mojo.   There is little we can do to bridge the gap other than
> > doing these macros.
>
> 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?
>
> For what it's worth, I've spoken to a couple of GCC devs over the last
> few years about supporting modern Objective-C (because I would like us
> to have a choice of compilers), but the effort involved for them is huge
> (even a naive ARC implementation is a big piece of effort) and the
> return is small (why would anyone use it?  Basically, the only target
> market is GNUstep developers on platforms that Clang doesn't support,
> which I think is a set containing only Riccardo).  There is some
> interest in supporting blocks, because Apple's libc headers no longer
> support compilers that don't support blocks, but even then I haven't
> seen much progress from GCC.
>
> David
>
> --
Sent from Gmail Mobile

Re: Embedded blocks...

[David Chisnall]

On 27/10/2019 16:05, Gregory Casamento wrote:
We are a GNU / FSF project.  Dropping support for GCC would be bad 
political mojo.   There is little we can do to bridge the gap other than 
doing these macros.


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?


For what it's worth, I've spoken to a couple of GCC devs over the last 
few years about supporting modern Objective-C (because I would like us 
to have a choice of compilers), but the effort involved for them is huge 
(even a naive ARC implementation is a big piece of effort) and the 
return is small (why would anyone use it?  Basically, the only target 
market is GNUstep developers on platforms that Clang doesn't support, 
which I think is a set containing only Riccardo).  There is some 
interest in supporting blocks, because Apple's libc headers no longer 
support compilers that don't support blocks, but even then I haven't 
seen much progress from GCC.


David

Re: Creating a block using the Macros....

[David Chisnall]

This is not possible in the general case.

A block is a structure containing:

 - A pointer to the invoke function.
 - The type info for the call.
 - A set of references to captured variables including:
   - Helpers to destroy any captured variables.
   - Helpers to copy any captured variables.

C macros are nowhere near expressive enough for this.  You could 
probably (just about) implement them using C++ templates, though it 
would be a lot of work.


The block macros give a way of allowing functions / methods that take 
blocks to be called, so that it is possible to build GNUstep with GCC 
and link it to a program built with clang.  To date, anything that needs 
to create blocks, we have implemented a different way or conditionally 
compiled out when building with GCC.


David

On 27/10/2019 15:55, Gregory Casamento wrote:
How do I create a block using the macros?  I know how to declare one, 
but not actually create one.   Doing it in clang is easy, but I need 
something that will work for both


Any ideas?

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

Mailtrack 
 
	Sender notified by
Mailtrack 
 
10/27/19, 11:53:53 AM 	

Re: Missing header file in base?

[Wolfgang Lux]

Yes, it appears a few bogus commits have ended up on trunk tonight. :-(


> Am 29.10.2019 um 09:17 schrieb Riccardo Mottola :
> 
> Hi,
> 
> if I compile base, I get this error:
> 
>  Compiling file NSMetadata.m ...
> In file included from NSMetadata.m:35:
> ../Headers/Foundation/NSMetadata.h:33:9: fatal error: 
> Foundation/NSMetadataAttributes.h: No such file or directory
>33 | #import 
>   | ^~~
> compilation terminated.
> make[4]: *** [/mingw64/System/Library/Makefiles/rules.make:479: 
> obj/libgnustep-base.obj/NSMetadata.m.o] Error 1
> make[3]: *** [/mingw64/System/Library/Makefiles/Instance/library.make:278: 
> internal-library-all_] Error 2
> 
> and indeed the file is not there in the git checkout.
> 
> Riccardo
> 

Missing header file in base?

[Riccardo Mottola]

Hi,

if I compile base, I get this error:

 Compiling file NSMetadata.m ...
In file included from NSMetadata.m:35:
../Headers/Foundation/NSMetadata.h:33:9: fatal error: 
Foundation/NSMetadataAttributes.h: No such file or directory

   33 | #import 
  | ^~~
compilation terminated.
make[4]: *** [/mingw64/System/Library/Makefiles/rules.make:479: 
obj/libgnustep-base.obj/NSMetadata.m.o] Error 1
make[3]: *** 
[/mingw64/System/Library/Makefiles/Instance/library.make:278: 
internal-library-all_] Error 2


and indeed the file is not there in the git checkout.

Riccardo