Re: Disappointed by GNUstep

[Fred Kiefer]

HI Wolfgang,

it is sad to read about you being disappointed by GNUstep. Especially on the 
one day where I was looking forward to join the GNUstep quarterly online 
meeting.

There are bugs in GNUstep and probably there always will be. We don’t get 
enough testing, usage, for GNUstep gun applications, so many bugs may go 
unnoticed for a long time. At least the first bug you mention below is 
something I already fixed on Christmas. I am surprised that you are still 
seeing it. We may be slow at detecting bugs, but many issues get resolved 
shortly after being reported.
As for the second issue, this is the first time I hear about it. And as you 
wrote it is probably fairly easy to fix after being able to reproduce it. Is 
there any standard GNUstep app that demonstrates this issue or do I have to 
construct one myself.

I don’t want to go into the compiler discussion here. This is a different point 
that should be discussed elsewhere.

I want to thank you for your previous contributions to GNUstep!

Cheers,
Fred

> Am 05.02.2022 um 17:57 schrieb Wolfgang Lux <wolfgang.lux@gmail.com>:
> 
> Hi,
> 
> when I started looking at GNUstep as means to port macOS (then Mac OS X) 
> applications to Linux/Windows about 15 years ago I found code that was quite 
> buggy and that kept crashing or not working as expected on the application I 
> tried to port at that time. I've contributed a number of patches to make the 
> GNUstep code more robust since then.
> In the past few years I hadn't time to contribute much to GNUstep (real life 
> intervening at its worst), so fast forward to last Spring when I started 
> looking back at that old hobby and was almost instantly greeted with another 
> crash. Not having that much of time and energy I "fixed" the problem by just 
> reverting to some revision of GNUstep gui/back shortly before the release of 
> 0.29.
> Now, having accidentally updated the code to head again I had another look at 
> this finding one cause for the crashes in NSPopUpButtonCell after a patch by 
> Riccardo to avoid leaking the menu associated with the cell when the cell is 
> deallocated. The patch looks correct to me, but the problem is that it 
> uncovers another bug: The _selectedItem may contain a dangling pointer after 
> setting the pop up button's menu to nil.
> The next issue, that I'm currently unable to attribute to any particular 
> patch, is a problem where a split view in a window loaded from a gorm file is 
> calling a method on its delegate after that delegate (which is the window 
> controller that has loaded the window in the first place) has been 
> deallocated (and hence the window itself should have been closed at this 
> point).
> The first of this issues has a fairly straightforward fix and for the second 
> one I might come up with a simple fix in my application to reset the split 
> view's delegate in the window controller's dealloc method. However, what 
> makes this so frustrating is that dangling pointers should not be an issue in 
> the first place in 2022. Automatic reference counting and zeroing weak 
> pointers have been around for a few years in clang and are supported the 
> GNUstep Objective-C runtime. However, this project prefers to stick to 
> obsolete technology (Richard mentioned gcc 4.0 as a baseline in another 
> comment), which means ARC and weak pointers are not an option. So IMHO, in 
> this regard people thinking this project is for nostalgics unfortunately is a 
> well deserved characterization of this project. :-(
> 
> Wolfgang
> 
> PS I characterized gcc as obsolete technology because there is little support 
> for Objective-C in gcc. The latest statement I seem to recall from another 
> thread was that the gcc developers don't care about breaking objc support; 
> but even if this weren't the case the Objective-C support is lagging far 
> behind clang (in particular with regard to memory management, which IMO has 
> always been one of the weak spots of Objective-C).