Re: Release schedule

[Chris B. Vetter]

On Fri, 4 Apr 2003 13:11:19 +0100
Richard Frith-Macdonald <address@hidden> wrote:
> A few points ...
> 1. I don't think NSSocketPort should be there as it's 
> incomplete/not-working
> Perhaps I'll remove it (I didn't add it) as I see no particular point 
> in having a non-working class there.

I do not know whether, and I didn't say that, NSSocketPort does not
work. What I was saying was, that I _tried_ to "disable" it, by defining
STRICT_OPENSTEP before include of NSPort.h, then turn it back off.

> 2. As to why it doesn't use a separate header ... for MacOS-X 
> compatibility as there is no particular reason to put it in a separate
> header when MacOS-X puts it in NSPort.h

*sigh*

> 3. Clashing with your own code ...
> If you just have a method '-socket' with a different return type,
> I agree that is an inconvenience and means you need to cast id's to
> the correct type.
> On the other hand, if you have your own NSSocketPort I have to say 
> that's your fault ... the class name uses the 'NS' prefix - which you
> are not supposed to use. That being said, I can't find the place in
> the spec where it says you shouldn't use the NS prefix yourself, so I
> guess there is an excuse:-)

I was working on a plain BSD socket class, where -socket returns an
object of that class, not an int.

Of course, I'm not stupid (enough ;-) to use an NS prefix. The problem
was that the compiler bitched about a method defined twice with
incompatible return types, one int, the other a class...

I eventually figured out a clean way around it, so I didn't push it.

> > Oh, yes, yes yes, you could use STRICT_OPENSTEP for including
> > NSPort.h-- alas STRICT_OPENSTEP DOESN'T F*CKING WORK.
> Please submit a bug report (or better, supply a patch to fix it)
> saying how/why and under what circumstances it doesn't work for you
> then.

Here's just one example what will happen, when STRICT_OPENSTEP is
defined:

In file included from
/opt/GNUstep/System/Headers/AppKit/NSApplication.h:32,
                 from NSApplication.h:52,
                 from NSApplication.m:49:
/opt/GNUstep/System/Headers/AppKit/NSResponder.h:44:
        error: parse error before "NSInterfaceStyle"
In file included from NSApplication.h:52,
                 from NSApplication.m:49:
/opt/GNUstep/System/Headers/AppKit/NSApplication.h:34:
        error: parse error before "class"
/opt/GNUstep/System/Headers/AppKit/NSApplication.h:81:
        error: parse error before "interface"
[...]

And I _did_ report that before.

> > *SIGH*
> > Looks to me like there are additions, extensions and "stuff" that
> > isn't even tested whether it will work.
> > And don't give me that "works here" ... it doesn't work here, and 
> > that's what matters to me (and my boss).
> Well it's ok to take that sort of attitude if you want, but it doesn't
> help ... If there are bugs that effect you but aren't reproducible by
> other people then your choices are to -
> 1. give up or
> 2. pay someone to help or
> 3. help fix things yourself.
> The beauty of free software projects is that you *have* that third 
> option, and if you fix things and contribute the fixes back, you also
> gain the satisfaction of having done something for the good of others.

I know _that_ attitude doesn't help. However, as said before (and you
probably recall), I sent bug reports and patches before, but it's kind
of frustrating when you run into the same problem(s) over and over
again, while your reports seem to get ignored, lost, used as fertilizer,
whatever... I hope I'll have a bit more spare time the coming weeks and
I will use it to take a closer look at problems that seem to be
particular to BSD and send in either reports or patches.

But I do apologize for having "lost it" yesterday - at least I got a
reaction out of it ;-)

-- 
Chris