Re: Embedded blocks...

[Riccardo Mottola]

Hi,

Yavor Doganov wrote:

В Tue, 29 Oct 2019 12:50:23 +, 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

Re: Embedded blocks...

[Yavor Doganov]

Jordan Schidlowsky wrote:
> > On Oct 31, 2019, at 2:47 PM, Yavor Doganov  wrote:
> > 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.

> Aren't all the listed architectures actually already supported in
> the latest llvm backend?  sparc, ppc, ppc64, powerpcspe and m68k all
> seem supported no?  I don't know if moving to clang would actually
> mean dropping support for these archs...

PowerPC flavors are supported, yes.  But not alpha, hppa, ia64, m68k,
riscv64, sh4, x32, hurd and kfreebsd.

> Also, i dunno, but I think when a new architecture arises it may
> actually be easier to support it in llvm in the future...  I don't
> know why this would be more effort in clang than any other compiler.

I don't know either but the RISCV porters said it was easier for them
to support GCC.

But I was talking about something different -- supporting a new
architecture is not only a toolchain issue.  The ppc64el porters are
still sending patches for packages that don't build successfully on
ppc64el and it's not exactly a new architecture.  GNUstep seldom needs
arch-specific patches (we didn't need to add any for riscv64) but some
other packages do.  If you restrict the build tests of particular
software only to a certain set of architectures it is possible that
its portability could decrease as time goes by.

Bertrand Dekoninck wrote:
> There should be some reasons why debian sticked to it.

As I said: there is no practical benefit.  More cons than pros.

There's also the Debian Policy which says that packages should be
built with the default compiler unless absolutely necessary.  It also
says that a package is buggy if it built on some architecture but that
is no longer the case.

> I don't know if there are plans to switch to libobjc2.

As it stands, no.  If the situation changes, we will reevaluate.  If
GNUstep drops GCC support we'll have no choice but to follow upstream.

Re: Embedded blocks...

[Jordan Schidlowsky]

> On Oct 31, 2019, at 2:47 PM, Yavor Doganov  wrote:
> 
> 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.


Aren't all the listed architectures actually already supported in the latest 
llvm backend?  sparc, ppc, ppc64, powerpcspe and m68k all seem supported no?  I 
don't know if moving to clang would actually mean dropping support for these 
archs...

Also, i dunno, but I think when a new architecture arises it may actually be 
easier to support it in llvm in the future...  I don't know why this would be 
more effort in clang than any other compiler.  In theory it should be less, 
cause it should be mostly llvm backend work.

Re: Embedded blocks...

[Gregory Casamento]

[image: Mailtrack]

Sender
notified by
Mailtrack

11/01/19,
11:59:15 AM

On Fri, Nov 1, 2019 at 2:02 AM 陈北宗  wrote:

> >
> > 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.
> >
> There is no point putting up a barrier too. One of the best selling point
> of GNUstep was “your whole existing codebase for a modern Mac OS X app is
> simply one recompile away from being useable on a lot of different
> computers” since it was almost 100% code compatible with Mac OS X back in
> the time. Now GNUstep has fell out of sync with macOS, this selling point
> is failing. This can result in GNUstep being reduced to a mere academic
> curiosity.
>

This is not true.  GNUstep has never been in sync with macOS.  Apple is a
billion dollar company with nothing but time to enhance the APIs.  It's
more than just Foundation and AppKit now and even those are difficult to
keep up with.   That being said I am working hard to get GNUstep
base/Foundation up to date with the current release.  I have about 15
classes left to implement at this point.

As of “Objective-C 2.0”, that was mostly compile-time changes made when
> Apple switched from GCC to LLVM/clang. Should there be an influx of patches
> for that, most of them would head towards GCC not GNUstep.


True.   Many people make the mistake of thinking GNUstep is responsible for
this.

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

Re: Embedded blocks...

[陈北宗]

> 
> 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.
> 
There is no point putting up a barrier too. One of the best selling point of 
GNUstep was “your whole existing codebase for a modern Mac OS X app is simply 
one recompile away from being useable on a lot of different computers” since it 
was almost 100% code compatible with Mac OS X back in the time. Now GNUstep has 
fell out of sync with macOS, this selling point is failing. This can result in 
GNUstep being reduced to a mere academic curiosity.

As of “Objective-C 2.0”, that was mostly compile-time changes made when Apple 
switched from GCC to LLVM/clang. Should there be an influx of patches for that, 
most of them would head towards GCC not GNUstep.

smime.p7s
Description: S/MIME cryptographic signature

Re: Embedded blocks...

[陈北宗]

> 
> Not this in particular, but I'm aware there is free software for Mac.
> Unfortunately, most of it is not readily available or easily portable
> because it a) depends on other nonfree libraries; b) relies on
> functionality not yet implemented on GNUstep (which would be the case
> even if GNUstep stopped supporting GCC).
> 

If GNUstep stayed with GCC, those missing functionalities can not be 
implemented at all; while if GNUstep dropped GCC, we can start working on those 
features and libraries.. From a practical standpoint, I would consider GCC’s 
Objective-C support broken beyond repair by this point really, since those new 
libraries and functionalities depends on entire new language features like 
Objective-C ARC, Blocks and extended Objective-C language. And there is the 
whole new can of worms of Swift integration, which requires the use of 
LLVM/clang since Swift itself is built on top of it, and there is no Swift in 
GCC at all.

As of LLVM/clang doing a better job at supporting the language, it is because 
Apple is on of the main contributors and actively feeds their language changes 
back to the mainline. 




smime.p7s
Description: S/MIME cryptographic signature

Re: Embedded blocks...

[Yavor Doganov]

On Fri, 01 Nov 2019 04:45:43 +0200,
lars.sonchocky-helld...@hamburg.de wrote:
> > Am 31.10.2019 um 21:47 schrieb Yavor Doganov :
> > 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.
> 
> This is FUD! LLVM is not under control by a single cooperation, it
> never was.

But I didn't say that.  The language is entirely under Apple's
control.  It is not developed by a committee or some independent
group.  Which means that when Apple decides to make changes,
implementors have to catch up.  Undoubtedly, LLVM/Clang is doing a
much better job than GCC on that front but this has its technical and
non-technical explanation.

> More FUD!
> 
> Are you aware of https://github.com/topics/objective-c
>  ?

Not this in particular, but I'm aware there is free software for Mac.
Unfortunately, most of it is not readily available or easily portable
because it a) depends on other nonfree libraries; b) relies on
functionality not yet implemented on GNUstep (which would be the case
even if GNUstep stopped supporting GCC).

Re: Embedded blocks...

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

> Am 31.10.2019 um 21:47 schrieb Yavor Doganov :
> 
>> 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?
> 
> You are right that it's a monumental effort and that they probably
> don't have the motivation.  The pool of free software written in
> Objective-C is rather small and it doesn't tend to increase.

More FUD!

Are you aware of https://github.com/topics/objective-c 
 ?

Or https://github.com/trending?l=objective-c 


Well, that might not be software ready for GNUstep, but it is Open Source 
Software written in ObjC.


Regarding GCC and ObjC: Some years ago I was regularly doing regression testing 
for GCC with a special focus on ObjC. I supported several regressions then:

https://gcc.gnu.org/bugzilla/buglist.cgi?cf_known_to_fail_type=allwords_known_to_work_type=allwords=lars.sonchocky-helldorf%40hamburg.de=1=1=substring=reporter_id=248707=equals_format=advanced
 


you are free to read the comments on those bugs. I only remember specific 
hostility towards ObjC on the part of GCC developers: bugs where closed as 
won’t fix or have been postponed over and over again as „being not release 
critically“, even regressions. My impression was that ObjC is simply not taken 
seriously by GCC developers. Instead, such marvels as D are praised on the 
homepage of GCC: https://gcc.gnu.org/gcc-9/changes.html#d 
 (linked prominently from 
https://gcc.gnu.org  ). For that reason I was very happy 
when LLVM/Clang finally appeared on the stage.

regards,

Lars

Re: Embedded blocks...

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

> Am 31.10.2019 um 21:47 schrieb Yavor Doganov :
> 
> В Tue, 29 Oct 2019 12:50:23 +, 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?
> 
> 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.

This is FUD! LLVM is not under control by a single cooperation, it never was. 
Instead it is „under control“ of the LLVM Foundation,

https://llvm.org/foundation/

which is: „a 501(c)(3) nonprofit whose mission is to support education and 
advancement of the field of compilers and tools through educational events, 
grants and scholarships, and increasing diversity with the field of compilers, 
tools, and the LLVM project. We have established 3 main programs: Educational 
Outreach, Grants & Scholarships, and Women in Compilers & Tools.
The Educational Outreach program is our largest program and includes 
educational materials and events related to the LLVM Project, compiler 
technology, and tools. Our 2 largest events are the LLVM Developers’ meetings 
located in the San Francisco Bay Area, and in Europe. These meetings serve as a 
forum for LLVM project developers, users, and academic researchers to get 
acquainted, learn how LLVM is used, and exchange ideas about LLVM and compiler 
technology. This program also includes educational materials such as 
instructional videos and full video recordings from our developer meetings that 
are available free to anyone.

The LLVM project is becoming one of the top platforms of choice for compiler 
research at universities. The Grants & Scholarships program is designed to 
support student presenter travel to the LLVM Developers’ Meetings and other 
conferences that students may attend and present their LLVM and compiler 
related work.

Lastly, our Women in Compilers & Tools program aims to increase female 
participation in the LLVM Project and the field of compilers and tools. We hope 
to achieve this by increasing awareness of the LLVM project at various 
technical conferences with strong female participation, established a mentor 
program, and lower barriers of entry for this field.“

cheers,

Lars

Re: Embedded blocks...

[Yavor Doganov]

В Tue, 29 Oct 2019 12:50:23 +, 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?

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).

> 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?

You are right that it's a monumental effort and that they probably
don't have the motivation.  The pool of free software written in
Objective-C is rather small and it doesn't tend to increase.

> 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.

As it stands, none of the GNUstep reverse dependencies currently in
Debian will benefit if we suddenly switch to LLVM/Clang.  We'll just
have to stop building the GNUstep stack on about half of the
architectures and at the end it will reflect back on GNUstep.

В 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.

> 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.

(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.)

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: Embedded blocks...

[Gregory Casamento]

The only way I can see to do it is to pull it out of the retTy structure,
but I am not sure that's the right way.

Things would be so much easier if we were to drop GCC from the list of
supported compilers since it doesn't enable many features which are needed
by most developers at this point.

GC

[image: Mailtrack]

Sender
notified by
Mailtrack

10/27/19,
11:56:05 AM

[image: Mailtrack]

Sender
notified by
Mailtrack

10/27/19,
11:57:35 AM

On Sat, Oct 26, 2019 at 12:36 PM 陈北宗  wrote:

> So you need a pointer to the inner block… I did not find any way of doing
> this using public API. You might have to dig into private API’s in
> libBlocksRuntime.
>
> On Oct 27, 2019, at 00:28, Gregory Casamento 
> wrote:
>
> I know how to handle it in the normal case.   The issue is how to pull it
> out of the gnustep specific strict to use it.
>
> On Sat, Oct 26, 2019, 11:28 AM 陈北宗  wrote:
>
>> What do you want to access it for? Invoking it? Copying it?
>>
>> If it is latter, just copying or retaining the outer block is adequate,
>> as copying the outer block will cause the inner block be retained, which
>> would copy it if it is a stack block.
>>
>> On Oct 26, 2019, at 22:42, Gregory Casamento 
>> wrote:
>>
>> Hey Guys,
>>
>> I am implementing the following class:
>>
>>
>> DEFINE_BLOCK_TYPE(NSBackgroundActivityCompletionHandler, void,
>> NSBackgroundActivityResult);
>> DEFINE_BLOCK_TYPE(GSScheduledBlock, void,
>> NSBackgroundActivityCompletionHandler);
>>
>> @interface NSBackgroundActivityScheduler : NSObject
>> {
>>   NSString *_identifier;
>>   NSQualityOfService _qualityOfService;
>>   NSTimeInterval _interval;
>>   NSTimeInterval _tolerance;
>>   BOOL _repeats;
>>   BOOL _shouldDefer;
>> }
>>
>> - (instancetype) initWithIdentifier: (NSString *)identifier;
>>
>> - (NSString *) identifier;
>> - (void) setIdentifier: (NSString *)identifier;
>>
>> - (NSQualityOfService) qualityOfService;
>> - (void) setQualityOfService: (NSQualityOfService)qualityOfService;
>>
>> - (BOOL) repeats;
>> - (void) setRepeats: (BOOL)flag;
>>
>> - (NSTimeInterval) interval;
>> - (void) setInterval: (NSTimeInterval)interval;
>>
>> - (NSTimeInterval) tolerance;
>> - (void) setTolerance: (NSTimeInterval)interval;
>>
>> - (BOOL) shouldDefer;
>> - (void) setShouldDefer: (BOOL)flag;
>>
>> - (void) scheduleWithBlock: (GSScheduledBlock)block;
>>
>> - (void) invalidate;
>>
>> @end
>>
>> How do I handle the embedded block GSScheduledBlock??  Declaring it this
>> way compiles, but I have no idea how to access the handler which is passed
>> in.
>>
>> Any clues?
>>
>> Thanks, 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
>> 
>>  10/26/19,
>> 10:39:17 AM
>>
>>
>>
>

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

Re: Embedded blocks...

[陈北宗]

So you need a pointer to the inner block… I did not find any way of doing this 
using public API. You might have to dig into private API’s in libBlocksRuntime.

> On Oct 27, 2019, at 00:28, Gregory Casamento  wrote:
> 
> I know how to handle it in the normal case.   The issue is how to pull it out 
> of the gnustep specific strict to use it.  
> 
> On Sat, Oct 26, 2019, 11:28 AM 陈北宗  > wrote:
> What do you want to access it for? Invoking it? Copying it?
> 
> If it is latter, just copying or retaining the outer block is adequate, as 
> copying the outer block will cause the inner block be retained, which would 
> copy it if it is a stack block.
> 
>> On Oct 26, 2019, at 22:42, Gregory Casamento > > wrote:
>> 
>> Hey Guys,
>> 
>> I am implementing the following class:
>> 
>> 
>> DEFINE_BLOCK_TYPE(NSBackgroundActivityCompletionHandler, void, 
>> NSBackgroundActivityResult);
>> DEFINE_BLOCK_TYPE(GSScheduledBlock, void, 
>> NSBackgroundActivityCompletionHandler);  
>> 
>> @interface NSBackgroundActivityScheduler : NSObject
>> {
>>   NSString *_identifier;
>>   NSQualityOfService _qualityOfService;
>>   NSTimeInterval _interval;
>>   NSTimeInterval _tolerance;
>>   BOOL _repeats;
>>   BOOL _shouldDefer;
>> }
>>   
>> - (instancetype) initWithIdentifier: (NSString *)identifier;
>> 
>> - (NSString *) identifier;
>> - (void) setIdentifier: (NSString *)identifier;
>> 
>> - (NSQualityOfService) qualityOfService;
>> - (void) setQualityOfService: (NSQualityOfService)qualityOfService;
>> 
>> - (BOOL) repeats;
>> - (void) setRepeats: (BOOL)flag;
>> 
>> - (NSTimeInterval) interval;
>> - (void) setInterval: (NSTimeInterval)interval;
>> 
>> - (NSTimeInterval) tolerance;
>> - (void) setTolerance: (NSTimeInterval)interval;
>> 
>> - (BOOL) shouldDefer;
>> - (void) setShouldDefer: (BOOL)flag;
>> 
>> - (void) scheduleWithBlock: (GSScheduledBlock)block;
>> 
>> - (void) invalidate;
>>   
>> @end
>> 
>> How do I handle the embedded block GSScheduledBlock??  Declaring it this way 
>> compiles, but I have no idea how to access the handler which is passed in.
>> 
>> Any clues?  
>> 
>> Thanks, GC
>> 
>> -- 
>> Gregory Casamento
>> GNUstep Lead Developer / OLC, Principal Consultant
>> http://www.gnustep.org  - 
>> http://heronsperch.blogspot.com 
>> http://ind.ie/phoenix/ 
>> 
>> 
>>   
>> 
>>  Sender notified by 
>> Mailtrack 
>> 
>>  10/26/19, 10:39:17 AM   
>> 
> 



smime.p7s
Description: S/MIME cryptographic signature

Re: Embedded blocks...

[Gregory Casamento]

I know how to handle it in the normal case.   The issue is how to pull it
out of the gnustep specific strict to use it.

On Sat, Oct 26, 2019, 11:28 AM 陈北宗  wrote:

> What do you want to access it for? Invoking it? Copying it?
>
> If it is latter, just copying or retaining the outer block is adequate, as
> copying the outer block will cause the inner block be retained, which would
> copy it if it is a stack block.
>
> On Oct 26, 2019, at 22:42, Gregory Casamento 
> wrote:
>
> Hey Guys,
>
> I am implementing the following class:
>
>
> DEFINE_BLOCK_TYPE(NSBackgroundActivityCompletionHandler, void,
> NSBackgroundActivityResult);
> DEFINE_BLOCK_TYPE(GSScheduledBlock, void,
> NSBackgroundActivityCompletionHandler);
>
> @interface NSBackgroundActivityScheduler : NSObject
> {
>   NSString *_identifier;
>   NSQualityOfService _qualityOfService;
>   NSTimeInterval _interval;
>   NSTimeInterval _tolerance;
>   BOOL _repeats;
>   BOOL _shouldDefer;
> }
>
> - (instancetype) initWithIdentifier: (NSString *)identifier;
>
> - (NSString *) identifier;
> - (void) setIdentifier: (NSString *)identifier;
>
> - (NSQualityOfService) qualityOfService;
> - (void) setQualityOfService: (NSQualityOfService)qualityOfService;
>
> - (BOOL) repeats;
> - (void) setRepeats: (BOOL)flag;
>
> - (NSTimeInterval) interval;
> - (void) setInterval: (NSTimeInterval)interval;
>
> - (NSTimeInterval) tolerance;
> - (void) setTolerance: (NSTimeInterval)interval;
>
> - (BOOL) shouldDefer;
> - (void) setShouldDefer: (BOOL)flag;
>
> - (void) scheduleWithBlock: (GSScheduledBlock)block;
>
> - (void) invalidate;
>
> @end
>
> How do I handle the embedded block GSScheduledBlock??  Declaring it this
> way compiles, but I have no idea how to access the handler which is passed
> in.
>
> Any clues?
>
> Thanks, 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
> 
>  10/26/19,
> 10:39:17 AM
>
>
>

Re: Embedded blocks...

[陈北宗]

What do you want to access it for? Invoking it? Copying it?

If it is latter, just copying or retaining the outer block is adequate, as 
copying the outer block will cause the inner block be retained, which would 
copy it if it is a stack block.

> On Oct 26, 2019, at 22:42, Gregory Casamento  wrote:
> 
> Hey Guys,
> 
> I am implementing the following class:
> 
> 
> DEFINE_BLOCK_TYPE(NSBackgroundActivityCompletionHandler, void, 
> NSBackgroundActivityResult);
> DEFINE_BLOCK_TYPE(GSScheduledBlock, void, 
> NSBackgroundActivityCompletionHandler);  
> 
> @interface NSBackgroundActivityScheduler : NSObject
> {
>   NSString *_identifier;
>   NSQualityOfService _qualityOfService;
>   NSTimeInterval _interval;
>   NSTimeInterval _tolerance;
>   BOOL _repeats;
>   BOOL _shouldDefer;
> }
>   
> - (instancetype) initWithIdentifier: (NSString *)identifier;
> 
> - (NSString *) identifier;
> - (void) setIdentifier: (NSString *)identifier;
> 
> - (NSQualityOfService) qualityOfService;
> - (void) setQualityOfService: (NSQualityOfService)qualityOfService;
> 
> - (BOOL) repeats;
> - (void) setRepeats: (BOOL)flag;
> 
> - (NSTimeInterval) interval;
> - (void) setInterval: (NSTimeInterval)interval;
> 
> - (NSTimeInterval) tolerance;
> - (void) setTolerance: (NSTimeInterval)interval;
> 
> - (BOOL) shouldDefer;
> - (void) setShouldDefer: (BOOL)flag;
> 
> - (void) scheduleWithBlock: (GSScheduledBlock)block;
> 
> - (void) invalidate;
>   
> @end
> 
> How do I handle the embedded block GSScheduledBlock??  Declaring it this way 
> compiles, but I have no idea how to access the handler which is passed in.
> 
> Any clues?  
> 
> Thanks, GC
> 
> -- 
> Gregory Casamento
> GNUstep Lead Developer / OLC, Principal Consultant
> http://www.gnustep.org  - 
> http://heronsperch.blogspot.com 
> http://ind.ie/phoenix/ 
> 
> 
>   
> 
>   Sender notified by 
> Mailtrack 
> 
>  10/26/19, 10:39:17 AM
> 



smime.p7s
Description: S/MIME cryptographic signature

Embedded blocks...

[Gregory Casamento]

Hey Guys,

I am implementing the following class:


DEFINE_BLOCK_TYPE(NSBackgroundActivityCompletionHandler, void,
NSBackgroundActivityResult);
DEFINE_BLOCK_TYPE(GSScheduledBlock, void,
NSBackgroundActivityCompletionHandler);

@interface NSBackgroundActivityScheduler : NSObject
{
  NSString *_identifier;
  NSQualityOfService _qualityOfService;
  NSTimeInterval _interval;
  NSTimeInterval _tolerance;
  BOOL _repeats;
  BOOL _shouldDefer;
}

- (instancetype) initWithIdentifier: (NSString *)identifier;

- (NSString *) identifier;
- (void) setIdentifier: (NSString *)identifier;

- (NSQualityOfService) qualityOfService;
- (void) setQualityOfService: (NSQualityOfService)qualityOfService;

- (BOOL) repeats;
- (void) setRepeats: (BOOL)flag;

- (NSTimeInterval) interval;
- (void) setInterval: (NSTimeInterval)interval;

- (NSTimeInterval) tolerance;
- (void) setTolerance: (NSTimeInterval)interval;

- (BOOL) shouldDefer;
- (void) setShouldDefer: (BOOL)flag;

- (void) scheduleWithBlock: (GSScheduledBlock)block;

- (void) invalidate;

@end

How do I handle the embedded block GSScheduledBlock??  Declaring it this
way compiles, but I have no idea how to access the handler which is passed
in.

Any clues?

Thanks, 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

10/26/19,
10:39:17 AM