Re: Disappointed by GNUstep

[Fred Kiefer]

Hi Wolfgang,

> Am 06.02.2022 um 16:30 schrieb Wolfgang Lux <wolfgang.lux@gmail.com>:
> 
>> 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.
> 
> maybe I should have spelled it out more clearly. I don't have that much of a 
> problem in general with my code crashing when I update to the latest version 
> of the tree, as long as isn't something that could easily be avoided. And 
> I've spent/wasted too much time debugging memory management related bugs in 
> Objective-C code (mostly outside the GNUstep libraries) so that I've lost 
> tolerance for such bugs these days. Therefore, I keep pestering people with 
> requests to switch to ARC when encountering such bugs.

Yes, ARC is a real improvement for application code. Not so much for libraries, 
as GNUstep is. Getting reference counting correct in procedural programming is 
not too hard in most case, but doing so declaratively just seems easier. You 
need to be very careful and provide the correct hints for the compiler to sort 
out things for you. I would expect that a switch here will cost us about two 
years until we got most of the declarations correct. Still the change would be 
worthwhile.

> Now regarding your fix it turns out I had missed it because I hadn't update 
> my local from github since early December. But then updating the code, I'm 
> afraid your fix doesn't really solve the issue. The main problem is that 
> _selectedItem may be dead after the statement
>  ASSIGN(_menu, menu);
> in method setMenu: and the code may setState: on _selectedItem in the 
> selectItem: method when altersStateOfSelectedItem is true for the pop up 
> button, which, unfortunately, is the default since commit 7023c7d. :-(

Ah, Testplant again. I am really not sure which bits of these changes are 
actually correct or just working around other issues they had at some time.

> I've committed another fix to resolve this issue. I had intended to create a 
> pull request for this, but I've accidentally committed it to master right 
> away. Feel free to update the code as you see fit.

Your change looks great to me, as always. Let's just hope it does not break 
anything for the other two issues that caused the different changes on that 
code. It really is hard to be sure as so many different combinations are 
possible with that code. The sad thing is that GNUstep gui code does not get 
the test exercise it would need. If twenty different applications depended on 
it on a daily bases we would have a lot more test cases out there and bugs 
would be ironed out more quickly.

>> 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.
> 
> No, it doesn't happen for a standard GNUstep application. And while it is 
> reproducible for me (in at least one case), it seems rather difficult to 
> narrow it down. I've tried to come up with a minimal example today, but 
> without luck so far (the examples were apparently too minimal). In fact, the 
> split view may just be a red herring and the real problem may be lurking 
> elsewhere. So don't bother trying to come up with a test case yourself.

Thank you for warning me. If you have a stack trace, feel free to send it to 
me. Maybe I could then guess where the problem is.

Cheers,
Fred