Re: Latest GNUstep feedback

[Fred Kiefer]

Hi Andreas,

again you just replied to me, but in English, so I think this mail is of
general interest and forward it to the mailing list.


Andreas Höschler schrieb:
> 
>>> I just upgraded to latest GNUstep/Etoile from svn. It took me a while
>>> but I finally got both trees to build on Solaris 10 SPARC. I will
>>> release the patched source tree on http://www.advanced-it.org/Downloads
>>> in a few hours if anyone is interested.
>>>
>>> My first observation is that
>>>
>>>     defaults write ...
>>>
>>> is very very slow now. Any idea why?
>>>
>>
>> Did you find the time to release your diff files? I just looked and only
>> found a full dump of core and etoile, including loads of .svn files.
> 
> Sorry, I was not aware anymore that I made this link public. The core
> tree was mainly intended for Patrick not for the public. And I actually
> put the files on http://www.smartsoft.de/Downloads/GNUstep-2007-02
> (higher bandwidth) not on www.advanced-it.org (the tree there is many
> months old). There should be only 20-30 differences to the svn version I
> downloaded a few day ago. In the meanwhile I have fixed two additional 
> issues. I will upload a new core for Patrick (and other interested
> parties) as soon as the core is working correctly again.
> 

Thank you for telling me, doing so before I downloaded the huge tar ball
and inspecting it would have saved much of my time and perhaps improved
my mood. The file at advanced-it was two days old and from what I can
tell without downloading the new one they look identical.

>> You surely know that those people who you expect to look at your code
>> change, closely follow SVN and even after a few days your tar ball will
>> be out of date and any diff will give us plenty of false differences we
>> need to look at.
>>
>> Do you want to get your changes discussed and may be into the main trunk
>> or are you just thinking about ways to make things complicated? Yes, I
>> am still a bit upset about your rather unfriendly mail on the NSTabView
>> issue, but this here is a real problem. Even after running diff with the
>>  -x .svn option I get a file with 11000 lines in it as a result.
> 
> As you might know from earlier discussions I document any modification
> to a downloaded svn tree in a private document "GNUstep modification" so
> that I can reapply the changes (if necessary) whenever I download a
> current svn again. Moreover, whenever I find a bug and a corresponding
> fix I make that public on the list. It is up to the GNUstep maintainers
> - somebody with write privileges to the svn tree - to either ignore
> these fixes (disagree) or include them in the main trunk.
> 

Where is this file? I could not find it in the tar ball I downloaded.
Why not just share this file with the mailing list?

> I unfortunately don't have the time to discuss each fix in a lengthy
> thread. The version I downloaded a few days ago worked not at all for
> me, so all I could do was to reapply all my patches (that I have made
> public) - some of my changes were already in the public tree (thanks to
> you), others were not, may be for good reason - and see whether the
> resulting version worked better. It did, but not good enough, so I had
> to perform some further investigations and discovered some modifications
> that have been made to the public tree in the last months that led to
> segmentation faults and aborts (in my applications). Again, I haven't 
> had the time to check each of these modifications in detail and try to
> figure out what the author of this mods meant to do. I just had to get a
> working tree again as quickly as possible, and the quickest way for me
> was to rollback to earlier versions of some method and leave the rest
> for public discussion.
> 

That is fine for you, you need to get your stuff working again. But this
approach wont help GNUstep or anybody apart from yourself. Have a look
again at the NSTabView discussion. Who do you thing help GNustep more,
you or Wolfgang Lux. and which approach is, in the long run, even better
for you?
You rolled back a perfectly valid change as it did uncover an up to then
hidden error in other code..

> I don't blame anyone. GNUstep is open-source and free after all. I don't
> expect a svn download to work as is in a productive environment. And my
> experience from a few days ago confirms this. I would love to discuss
> each issue in length on the list. Unfortunately I don't have the time
> for this. All I can do is share my modifications with the public in a
> timely efficient manner, and until now this was to simply post my fixes
> on the list.

Yes, but please not just efficient for you. It must be manageable for us
as well.

> 
> I am open to learn about more efficient approaches for sharing fixes.
> 

Great, lets start on this.

>> This only two days after you uploaded your version. OK, most of these
>> lines
>> are due to my subverion using German week day abbreviations when
>> replacing the date in the header instead of the English names you are
>> using. Others are clearly changes done within GNUstep during these days.
>> In the first 2000 lines I could only identify some change to
>> NSNumberFormatter to be done by you. This changes will only work
>> correctly for German language settings and I am really not sure, if it
>> is still needed with current GNUstep code.
> 
> Nor am I. That's part of the problem. I need a working tree for my
> customer(s). I can't afford to think about whether a fix I apply works
> with Japanese language settings as well. I just apply the patch to solve
> my problem and go on to the next problem. That's why it might be
> legitimate that not all of my fixes go into the main trunk (no general
> solution to the problem). I can live with that. That's what I have my
> "GNUstep modifications" document for.
> 

Sorry, you seem to get me wrong. I was trying to say that I think it is
possible that your change is even no longer needed for German language
settings. Did you test if it is still required?

>> Why don't you save us this work and simply type in svn diff in your core
>> directory and pipe the output into a file and write up some
> 
> -bash-3.00# cd /usr/src/core
> -bash-3.00# svn diff
> svn: '.' is not a working copy
> 
> Hmmh?

OK, this is one of the drawbacks of using SVN. We now need to diff in
each module directory separately. That is you need to get separate diffs
for make, base, gui and back. What is strange is that I don't get an
error message as you do, SVN just wont report any changes.

> 
>> documentation coming along with that file to explain why you thing each
>> of the changes you did is needed?
> 
> You are right. I have to spend more time on documenting what problems my
> patches fix. The remarks in my "GNUstep modifications" document and in
> the postings to the list are often a little short.
> 
> However, I am wondering why I still encounter so many issues with a
> clean svn build that I need to schedule 2-3 days after each svn download
> to make it ready for productive usage. Am I the only one that is using
> gui in a productive manner? Again, this is no blame but rather what I
> expect from an open-source project. Let's take your change to NSTabView.
> I am sure you had a good reason/idea to apply this patch and I am happy
> that you and other good programmers are working on and trying to improve
> GNUstep. However, what I would be interested in is how long this patch
> was in the tree without anyone realizing that it breaks every
> application that makes use of an NSTabView. I mean... Is anybody really
> using GNUstep GUI (except Smartsoft)? Or do I have a weird kind of
> programming that only my applications break (that work well under
> MacOSX) and the apps of others don't?
> 

You don't need to wonder here. Just check the Changelog file of gui.
There you will see that the changes on NSTabView were done on the 20th
of Febuary. Did you look at the other changes I made to NSTabView? Most
of it were comments that point to other changes that are needed to get
this class fully functional. I don't have the impression that I made
wild changes there, without thinking about the results. Changing the
enumerator values, which I want to do any time soon, will be a big
change, that requires additional changes to Gorm, but what I did then
looked pretty save to me. Perhaps you could see the problem right away,
but I am just a normal programmer. And the program I tested that change
with worked better after it then before.

What you suggest about GNUstep GUI not being use, is again not the most
positive approach to this subject. There are applications out there
using GNUstep gui and some of them are surely productions strength. They
may not use the same features of GNUstep as your applications do, may
not require to run on Solaris or just missed to update GNUstep for the
last week.


> In my opinion this is the serious problem we have with GNUstep. It is
> worked on by some good developers (even the best make mistakes) but it
> is hardly used by them so problems/bugs are not discovered. :-(
> 

I would say that reporting bugs is not just a task for core developers,
of which there are too few, but everybody using GNUstep should report
bugs with as much information as possible. Remember that NSMatrix change
you send in a week ago? Who ever had implemented GSDock knew that
GNUstep was behaving different from Cocoa, but I don't remember a bug
report for this in our bug tracking system.

Cheers,
Fred