Dear List,
There are over and over again arguments on moving on to LLVM/clang for latest
language features versus maintaining compatibility with old/uncommon platforms
and GCC, to the point that IMO we are so far behind on language feature parity
with Apple releases. With the most glaring hole
> On 14 Feb 2022, at 11:43, Max Chan wrote:
>
> Dear List,
>
> There are over and over again arguments on moving on to LLVM/clang for latest
> language features versus maintaining compatibility with old/uncommon
> platforms and GCC,
Really this is simply not the case among GNUstep develope
> On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald
> wrote:
>
>
>
>> On 14 Feb 2022, at 11:43, Max Chan wrote:
>>
>> Dear List,
>>
>> There are over and over again arguments on moving on to LLVM/clang for
>> latest language features versus maintaining compatibility with old/uncommon
> On 14 Feb 2022, at 14:59, Max Chan wrote:
>
>
>> On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald
>> wrote:
>>
>>
>>
>>> On 14 Feb 2022, at 11:43, Max Chan wrote:
>>>
>>> Dear List,
>>>
>>> There are over and over again arguments on moving on to LLVM/clang for
>>> latest langua
Richard Frith-Macdonald wrote on 14.02.22 17:43:
>
>> On 14 Feb 2022, at 14:59, Max Chan wrote:
>>
>>
>>> On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald
>>> wrote:
>>>
>>>
>>>
On 14 Feb 2022, at 11:43, Max Chan wrote:
Dear List,
There are over and over again ar
Sorry I just realized I misread "ancient version of the language" for "using
GCC". It still doesn’t seem like a big deal to me wrt. contributing, but then
again my changes were usually pretty contained.
> Am 14.02.2022 um 20:30 schrieb Frederik Seiffert :
>
>
>
>> Am 14.02.2022 um 18:39 schr
> Am 14.02.2022 um 18:39 schrieb Andreas Fink :
>
> It does the project a huge reality check to tell developers they 'have to use
> an ancient version of the language *IF THEY WANT TO CONTRIBUTE TO GNUSTEP*'.
Why do you think that’s the case? I’ve contributed many changes over the last
years
> On Feb 14, 2022, at 12:39 PM, Andreas Fink wrote:
>
>
>
> Richard Frith-Macdonald wrote on 14.02.22 17:43:
>>
>>> On 14 Feb 2022, at 14:59, Max Chan wrote:
>>>
>>>
On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald
wrote:
> On 14 Feb 2022, at 11:43, M
> On 14 Feb 2022, at 17:39, Andreas Fink wrote:
>
>
>
> Richard Frith-Macdonald wrote on 14.02.22 17:43:
>>
>>> On 14 Feb 2022, at 14:59, Max Chan wrote:
>>>
>>>
On Feb 14, 2022, at 8:23 AM, Richard Frith-Macdonald
wrote:
> On 14 Feb 2022, at 11:43, Max
Andreas,
We don't have to tell developers who develop applications that because
GNUstep currently works with clang. Most of the issues mentioned (i.e.
"new" features) are compiler-specific. It is a common misconception that
GNUstep has anything to do with GCC's feature set or that we are, someho
Having so many branches will confuse things greatly. I am not sure it's a
good idea to split the project like this. Also, with many branches
divergence becomes a greater possibility which might complicate merging.
On Mon, Feb 14, 2022 at 3:11 PM Max Chan wrote:
>
>
> > On Feb 14, 2022, at 12:3
How many branches do we currently have?
When coming to merging, I am okay if those two branches never truly merge. The
mainline branch basically stays in line with Mac OS X 10.6.8, conveniently the
last release of macOS with GCC support from Apple as well. While the Next
branch chases the lates
Hi Frederik,
Frederik Seiffert wrote:
>
> I’d never write any new *app* code without ARC, and would definitely
> recommend converting any existing apps if you can control the
> environment where they are built, but IMO it’s fine that the GNUstep
> libraries don’t use it – it definitely doesn’t k
> The mainline branch focuses on maintaining the highly portable codebase,
> while the Next branch focuses on features and library support, free to break
> compatibility with anything that is less than popular in the wild
There are multiple problems with your proposal that are obvious when worki
> On Feb 14, 2022, at 3:45 PM, Richard Frith-Macdonald
> wrote:
>
> If you wanted to say that GNUstep is *extremely* reluctant to break
> portability of existing code, that would also be fine and true. it's also a
> non-issue in practice: who wants to rewrite working code to make it less
>
Hi,
Gregory Casamento wrote:
> GNUstep's core code tries to remain as compatible as possible with both
> tool-chains. This is done very much on purpose. When using clang, you
> can use many of the ObjC2.0 features. The main one missing is ARC, and
> that is the main one I am concerned about.
B
> On Feb 14, 2022, at 6:06 PM, Riccardo Mottola
> wrote:
>
> I continue to think that a restriction into core libraries is
> acceptable, if it leaves the freedom for your "app code" (or... other
> code you need of course).
>
The problem is that our core libraries are dreadfully outdated. It
> On Feb 14, 2022, at 6:18 PM, Riccardo Mottola
> wrote:
>
> Hi,
>
> Gregory Casamento wrote:
>> GNUstep's core code tries to remain as compatible as possible with both
>> tool-chains. This is done very much on purpose. When using clang, you
>> can use many of the ObjC2.0 features. The mai
On 2022-02-15 03:38:32 +0400 Max Chan wrote:
in dire need of refactor, ...
The biggest refactor project
A casual observation:
Many fans of automatic memory management (being it ARC or GC) love
refactoring.
So much for "spending time finding bugs that are impossible by
construction with
Max,
On Mon, Feb 14, 2022 at 6:02 PM Max Chan wrote:
> How many branches do we currently have?
>
>
Only one that contains the current code, that being "master". All other
branches are feature branches or PR branches which are eventually merged
back in and deleted.
> When coming to merging, I
> On Feb 15, 2022, at 2:07 AM, Gregory Casamento
> wrote:
>
>
> Max,
>
> When coming to merging, I am okay if those two branches never truly merge.
>
> I'm not.
Come to think of it, if we do chase the latest feature especially Swift
compatibility, we get Swift Package Manager along with it
This is just whack…
What I mean by saying we need refactoring, is that our library structure is
twisted and may not bode well for future Swift integration. Here is ours:
* libc
* libobjc2
* Foundation (NSObject here)
* CoreFoundation
And here is Apple’s:
* libc
* libobjc2 (NSObje
> Am 15.02.2022 um 08:36 schrieb Max Chan :
>
> Come to think of it, if we do chase the latest feature especially Swift
> compatibility, we get Swift Package Manager along with it which can be used
> as a parallel build system bypassing gnustep-make.
Hm. To me it looks as two distinct projects
> Am 15.02.2022 um 08:44 schrieb Max Chan :
>
> This is just whack…
>
> What I mean by saying we need refactoring, is that our library structure is
> twisted and may not bode well for future Swift integration. Here is ours:
>
> * libc
> * libobjc2
>* Foundation (NSObject here)
> *
> On Feb 15, 2022, at 2:54 AM, H. Nikolaus Schaller wrote:
>
>> Am 15.02.2022 um 08:36 schrieb Max Chan :
>>
>> Come to think of it, if we do chase the latest feature especially Swift
>> compatibility, we get Swift Package Manager along with it which can be used
>> as a parallel build system
This kind of layering is the easiest and the most robust way of implementing
all those toll-free bridging. You can see where NSObject lives as that is
required or toll free bridging to work. Also through my probing a lot of
Foundation classes actually lives in CoreFoundation binary.
If we build
> On 15 Feb 2022, at 08:13, Max Chan wrote:
>
>
>
>> On Feb 15, 2022, at 2:54 AM, H. Nikolaus Schaller wrote:
>>
>>> Am 15.02.2022 um 08:36 schrieb Max Chan :
>>>
>>> Come to think of it, if we do chase the latest feature especially Swift
>>> compatibility, we get Swift Package Manager a
Riccardo Mottola wrote on 15.02.22 00:06:
> Hi Frederik,
>
>
> Frederik Seiffert wrote:
>> I’d never write any new *app* code without ARC, and would definitely
>> recommend converting any existing apps if you can control the
>> environment where they are built, but IMO it’s fine that the GNUstep
Hi Max,
Max Chan wrote:
> The problem is that our core libraries are dreadfully outdated. It is on par
> with Mac OS X 10.6.8, which is a decade old now. This whole Next branch idea
> is to remove the restriction on the new branch so people interested in or
> need new features can chase the la
Question:
is it time to start working on libobjc3 with Swift support and support
for all platforms we want to support?
(if libobj3 is an upgrade of libobjc2 or a rewrite being put aside for now).
Apple will run away in a decade with Swift only. So if our goal is to
keep OS X compatibility, then we
> On Feb 15, 2022, at 7:24 AM, Riccardo Mottola
> wrote:
>
> Hi Max,
>
> Also, swift is designed to be objective-c interoperable. So while I
> don't use it myself, it should not require a rewrite ot core.
I have actually asked on the Swift folks on their reason why they do not enable
intero
I mostly haven’t chimed in here because others covered my points for me. But I
feel like reiterating what I said on stream the other night.
As a copyleft and GNU fan, it causes me deep emotional pin that we’re
considering targeting something other than GCC as our primary tool chain.
BUT
We a
> On Feb 15, 2022, at 7:10 AM, Andreas Fink wrote:
>
> Question:
> is it time to start working on libobjc3 with Swift support and support
> for all platforms we want to support?
> (if libobj3 is an upgrade of libobjc2 or a rewrite being put aside for now).
Or should we just work backwards, bui
I don't know about the level of changes needed in GCC, or about the
possibility of using an objC preprocessor, but it was possible to
build and deploy ARC using (including __weak references) code to 10.6.8.
As I recall one had to build against the 10.7 SDK, and then add an
extra package for the __
> Am 15.02.2022 um 15:10 schrieb Derek Fawcus
> :
>
> I don't know about the level of changes needed in GCC, or about the
> possibility of using an objC preprocessor, but it was possible to
> build and deploy ARC using (including __weak references) code to 10.6.8.
>
> As I recall one had to bu
One of the features of ARC is weak pointers, which clears itself to nil once
the referenced object is deallocated. Mac OS X 10.6.8 has a backported weak
pointer (the one Derek mentioned) and iOS 4.3.5 does not support weak pointers
at all. This self-clearing behavior of weak pointer is what requ
Max Chan wrote:
> To be honest ARC is less of a concern for me right now - GCC can gain that
> (and the syntactic sugars) very easily as long as GCC folks can pick up their
> s#!t. The big feature of concern IMO is Swift, which does not have any GCC
> frontend and likely uses a different ABI as
> On Feb 16, 2022, at 2:58 PM, Riccardo Mottola
> wrote:
>
> No, we don't need that. Your opinion.
We need to do this if we don’t want to screw up performance of Swift-only
programs. There is no point forcing even small, simple Swift-only programs to
operate in full Objective-C compatibilit
38 matches
Mail list logo
