> On 14 Feb 2022, at 16:38, Xavier Brochard wrote:
>
> Hi everyone
>
> By reading this discussion, I was thinking there is a problem that no one
> talk about. This email from Riccardo is a good starting point:
>
> Le 14.02.2022 00:11, Riccardo Mottola a écrit :
>> But what is a user? I can
Hi everyone
By reading this discussion, I was thinking there is a problem that no
one talk about. This email from Riccardo is a good starting point:
Le 14.02.2022 00:11, Riccardo Mottola a écrit :
But what is a user? I can think at least of two types.
1) User of GNUstep libraries because
Hi,
Hugo Melder wrote:
> Mainly Windows support and some signature differences between Apple's
> runtime (private APIs etc). The libobjc2 github repository keeps track
> of that in the issues segment.
I wonder if - besides ARC which is a compiler feature - we could make
the GCC runtime more
> On 14 Feb 2022, at 08:54, Andreas Fink wrote:
>
>
>
> Daniel Boyd wrote on 14.02.22 08:54:
>> Riccardo,
>>
>> Thanks for the response. I agree there is certainly a distinction between
>> the user types and I, as a developer myself, was referring to #2. However, I
>> disagree that
Daniel Boyd wrote on 14.02.22 08:54:
> Riccardo,
>
> Thanks for the response. I agree there is certainly a distinction between the
> user types and I, as a developer myself, was referring to #2. However, I
> disagree that catering to each group is equally important at this juncture
> for two
Riccardo,
Thanks for the response. I agree there is certainly a distinction between the
user types and I, as a developer myself, was referring to #2. However, I
disagree that catering to each group is equally important at this juncture for
two reasons:
1) GNUstep doesn’t currently have
Hi,
On 2022-02-10 02:31:44 + Gregory Casamento
wrote:
Riccardo,
I don't believe that GNUstep should hold back features to remain
compatible
with any given compiler. Not implementing features that are widely
used
(not even particularly "modern" ones) because the less capable
Hi,
On 2022-02-06 10:51:49 + Richard Frith-Macdonald
wrote:
I think general portability is an issue, not just MSYS.
MSYS is very sensitive itself - it took 2 years of work to upgrade
from the original "msys 1" setup with gcc 3.4 (all newer gcc's had
subtle issues!) to a failry
Hi Daniel,
I think unvoluntary you made a very important point, I don't know by being
aware of it or not.
> If you’re looking to recruit more GNUStep users, I just don’t think you
> can do that without ARC, @[], @{}, etc. There are plenty of ObjC developers
> out there right now who are
Mainly Windows support and some signature differences between Apple's runtime
(private APIs etc). The libobjc2 github repository keeps track of that in the
issues segment.
On February 10, 2022 2:37:55 PM GMT+01:00, Andreas Fink
wrote:
>What are the real issues of the runtime on other
What are the real issues of the runtime on other platforms?
I might have a personal interest to do some work on some platforms.
Gregory Casamento wrote on 10.02.22 03:31:
> Riccardo,
>
> I don't believe that GNUstep should hold back features to remain
> compatible with any given compiler. Not
Riccardo,
I don't believe that GNUstep should hold back features to remain compatible
with any given compiler. Not implementing features that are widely used
(not even particularly "modern" ones) because the less capable compiler (in
this case the latest GCC) lacks support is not a healthy
Hi,
On 2022-02-06 19:55:10 + Richard Frith-Macdonald
wrote:
Yes, I remember thinking (and should have said) that I know of no
bugs in the
GCC implementation (though of course there may be some), and that a
bad
release many years ago is not indicative of current or recent support.
Hi,
sorry for being a little bit absent, day-job is overtaking, I skipped
the meeting and had no energy to reply. Also, the words chosen
irritated me and spoke to you guys separately.
Let me start with a reply on the facts given which here are then mixed
with judgments which are personal of
No. I don’t think this is a good idea. I really have no desire to maintain
a fork of GCC.
On Mon, Feb 7, 2022 at 12:32 Max Chan wrote:
> Dear Mr. Casamento:
>
> I wonder if it is appropriate to just copy/paste code from LLVM/clang into
> GCC? Legally speaking LLVM/clang is under a permissive
Dear Mr. Casamento:
I wonder if it is appropriate to just copy/paste code from LLVM/clang into GCC?
Legally speaking LLVM/clang is under a permissive license which should allow
redistribution under GPLv3. Politically speaking I have no idea.
If there is nothing stopping us from doing the
Andrew,
On Sun, Feb 6, 2022 at 10:03 PM Andrew Pinski wrote:
> On Sun, Feb 6, 2022 at 6:44 PM Gregory Casamento
> wrote:
> >
> >
> > Tito,
> >
> > On Sun, Feb 6, 2022 at 7:53 PM Tito Mari Francis Escaño <
> titomarifran...@gmail.com> wrote:
> >>
> >> Hi everyone,
> >> I think the GNUstep
On Sun, Feb 6, 2022 at 6:44 PM Gregory Casamento
wrote:
>
>
> Tito,
>
> On Sun, Feb 6, 2022 at 7:53 PM Tito Mari Francis Escaño
> wrote:
>>
>> Hi everyone,
>> I think the GNUstep project will have to be pragmatic based on the project
>> goals, and the goals we also have to re-evaluate:
>> 1)
Tito,
On Sun, Feb 6, 2022 at 7:53 PM Tito Mari Francis Escaño <
titomarifran...@gmail.com> wrote:
> Hi everyone,
> I think the GNUstep project will have to be pragmatic based on the project
> goals, and the goals we also have to re-evaluate:
> 1) Is GNUstep as a project required to be and should
Hi everyone,
I think the GNUstep project will have to be pragmatic based on the project
goals, and the goals we also have to re-evaluate:
1) Is GNUstep as a project required to be and should functionally be tied
closely with the GCC toolchain?
2) Is GNUstep required to use GCC toolchain to
I think the decision needs to tie back to the core mission of the project. I’m
not 100% sure what that is. Is it “Grow the GNUStep user base?” Or is it
“Maintain a fully copy-left tool chain?” Or some combination?
Honesty, either way, I think llvm/clang is the right choice right now. The
Fred,
On Sun, Feb 6, 2022 at 2:09 PM Fred Kiefer wrote:
>
>
> > Am 06.02.2022 um 01:14 schrieb Gregory Casamento <
> greg.casame...@gmail.com>:
> >
> > There are a number of factors that are driving this:
> > --
> > 1) GCC lacks support for many memory management features that are
> commonly
> On 6 Feb 2022, at 19:09, Fred Kiefer wrote:
>
>
>
>> Am 06.02.2022 um 01:14 schrieb Gregory Casamento :
>>
>> There are a number of factors that are driving this:
>> --
>> 1) GCC lacks support for many memory management features that are commonly
>> used today
>> 2) GCC's objective-c
> Am 06.02.2022 um 01:14 schrieb Gregory Casamento :
>
> There are a number of factors that are driving this:
> --
> 1) GCC lacks support for many memory management features that are commonly
> used today
> 2) GCC's objective-c support is lagging behind and doesn't include support
> for @[],
Hi Max,
> Apple has released Swift for Linux amd64 and Windows. Can we piggyback on
> that?
The Objective-C interoperability layer of the Swift programming language
depends on the internal Apple Objective-C runtime and is therefore not
available on Linux and Windows. It is possible to
> On 6 Feb 2022, at 09:35, Andreas Fink wrote:
>
> So to summarize up, we need to get libobjc2 properly working under MSYS2 and
> we can continue with clang.
> What are the isuses with libobjc2 not working under MSYS2? From what I know
> libobj2 should not have many dependencies on the
So to summarize up, we need to get libobjc2 properly working under MSYS2
and we can continue with clang.
What are the isuses with libobjc2 not working under MSYS2? From what I
know libobj2 should not have many dependencies on the operating system
itself (well memory management and multithreading
Just a thought, Apple has released Swift for Linux amd64 and Windows. Can we
piggyback on that? That means on Windows even if libobjc2 turns out to be
almost impossible to implement people can still use Swift libraries to achieve
the same.
Sent from my iPad
> On Feb 5, 2022, at 7:17 PM,
All,
As promised in my reply to Wolfgang, I am starting the thread regarding
this migration.
There are a number of factors that are driving this:
--
1) GCC lacks support for many memory management features that are commonly
used today
2) GCC's objective-c support is lagging behind and doesn't
29 matches
Mail list logo
