PING: Question: Need to store ObjC-specific info in type nodes.

PING: Question: Need to store ObjC-specific info in type nodes.

[Ziemowit Laski]

Please, folks -- this ain't rocket science...

Does any C, C++ and/or global maintainer object to my proceeding with 
(3) below?
----

Currently, ObjC does some rather ghastly things with accessors such as 
TYPE_CONTEXT, TREE_PUBLIC and TYPE_MAIN_VARIANT, which are used for its 
own merry purposes in RECORD_TYPEs.  This is a horrible state of 
affairs, and so I'd like to clean up the way ObjC stores its own 
information so that it plays nice(r) with what C and C++ expect.  (This 
work is part of the ongoing ObjC++ integration, BTW, so a prompt 
response would be appreciated.)

There seem to be several ways of attacking this, but I'd like to ask 
the powers that be for the preferred approach before actually 
undertaking it:
(1)  The additional info required for ObjC RECORD_TYPEs is stored as 
attributes, which peacefully co-exist with C/C++ attributes in the
      TYPE_ATTRIBUTES accessor.
(2)  In addition to a 'struct lang_type *lang_specific' field, each 
type node also gets a 'struct objc_lang_type *objc_lang_specific' field 
(set to NULL in plain C and C++ modes).
(3)  A variation of (2) in which 'struct lang_type' itself (both in C 
and C++) gets 'struct objc_lang_type *objc_lang_specific' field.

Which of these would be preferable and/or have I left out other 
possibilities?  It seems that (1) would require least (if any!) changes 
to existing GCC infrastructure, but the resulting ObjC/ObjC++ 
compile-time performance would be less than stellar.  Personally, I 
favor (3).

Please advise,

--Zem

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Zack Weinberg]

Ziemowit Laski <zlaski@apple.com> writes:

> Please, folks -- this ain't rocket science...

You posted your question three hours ago.  Generally it takes at least
a day to get an answer out of anyone.

I find either (1) or (3) infinitely preferable to (2), and would
suggest you consider a (3a) in which the ObjC/ObjC++ front ends
enlarge the C/C++ lang_type structures (in much the same way that all
these front ends currently build on struct c_common_identifier to
create their struct lang_identifier).  This is preferable to (3) if
the additional data is small (up to, say, four pointers), or if it
needs allocating for practically every RECORD_TYPE.  If it is both
large and rarely needed, your original (3) is better.

You should determine the answer to the question "is it rarely needed?"
by measurement of real code.

zw

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Matt Austern]

On Sep 23, 2004, at 6:36 PM, Zack Weinberg wrote:

> Ziemowit Laski <zlaski@apple.com> writes:
>
>> Please, folks -- this ain't rocket science...
>
> You posted your question three hours ago.  Generally it takes at least
> a day to get an answer out of anyone.
>
> I find either (1) or (3) infinitely preferable to (2), and would
> suggest you consider a (3a) in which the ObjC/ObjC++ front ends
> enlarge the C/C++ lang_type structures (in much the same way that all
> these front ends currently build on struct c_common_identifier to
> create their struct lang_identifier).  This is preferable to (3) if
> the additional data is small (up to, say, four pointers), or if it
> needs allocating for practically every RECORD_TYPE.  If it is both
> large and rarely needed, your original (3) is better.
>
> You should determine the answer to the question "is it rarely needed?"
> by measurement of real code.

As I commented offline, the other thing to consider is that attributes
(even with Geoff's rewrite) are expensive.  Zem's suggestion #1 would
probably only be a good idea if this information is *really* rarely
needed.

			--Matt

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Ziemowit Laski]

On 23 Sep 2004, at 18.40, Matt Austern wrote:

> On Sep 23, 2004, at 6:36 PM, Zack Weinberg wrote:
>
>> Ziemowit Laski <zlaski@apple.com> writes:
>>
>>> Please, folks -- this ain't rocket science...
>>
>> You posted your question three hours ago.  Generally it takes at least
>> a day to get an answer out of anyone.
>>
>> I find either (1) or (3) infinitely preferable to (2), and would
>> suggest you consider a (3a) in which the ObjC/ObjC++ front ends
>> enlarge the C/C++ lang_type structures (in much the same way that all
>> these front ends currently build on struct c_common_identifier to
>> create their struct lang_identifier).  This is preferable to (3) if
>> the additional data is small (up to, say, four pointers), or if it
>> needs allocating for practically every RECORD_TYPE.  If it is both
>> large and rarely needed, your original (3) is better.
>>
>> You should determine the answer to the question "is it rarely needed?"
>> by measurement of real code.
>
> As I commented offline, the other thing to consider is that attributes
> (even with Geoff's rewrite) are expensive.  Zem's suggestion #1 would
> probably only be a good idea if this information is *really* rarely
> needed.

Agreed; unfortunately, all ObjC structs will need this, so I don't think
that "rarely" applies.  I'll investigate doing (3a), and see where that 
goes.

--Zem

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Ziemowit Laski]

On 23 Sep 2004, at 18.36, Zack Weinberg wrote:

> Ziemowit Laski <zlaski@apple.com> writes:
>
>> Please, folks -- this ain't rocket science...
>
> You posted your question three hours ago.  Generally it takes at least
> a day to get an answer out of anyone.

That's nonsense, and the 'attribute data structure rewrite' thread 
proves it.
Of course, I can't really force anyone to respond to my questions in a 
timely
(let alone courteous) manner.  But I can (and, if necessary, will) hold 
up
the release of gcc 4.0 until all of ObjC++ is integrated.

> I find either (1) or (3) infinitely preferable to (2), and would
> suggest you consider a (3a) in which the ObjC/ObjC++ front ends
> enlarge the C/C++ lang_type structures (in much the same way that all
> these front ends currently build on struct c_common_identifier to
> create their struct lang_identifier).  This is preferable to (3) if
> the additional data is small (up to, say, four pointers), or if it
> needs allocating for practically every RECORD_TYPE.  If it is both
> large and rarely needed, your original (3) is better.

The usage patterns would definitely lean towards (3a).  I guess I'll 
investigate
the c_common_identifier/lang_identifier machinery.

Thanks,

--Zem

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Steve Naroff]

Of the choices you've outlined, I agree that (3) sounds best.

It would be nice to have a solution that doesn't require NULL slots for 
C/C++ (when not being used in the context ObjC, obviously). The tree's 
are already full of NULL fields...I would hate to add overhead for this 
reason.

btw...the terms "ghastly" and "horrible state of affairs seem a bit 
dramatic", eh? Take a deep breath - we'll get you through this 
difficult transition:-)

snaroff

On Sep 23, 2004, at 6:19 PM, Ziemowit Laski wrote:

> Please, folks -- this ain't rocket science...
>
> Does any C, C++ and/or global maintainer object to my proceeding with 
> (3) below?
> ----
>
> Currently, ObjC does some rather ghastly things with accessors such as 
> TYPE_CONTEXT, TREE_PUBLIC and TYPE_MAIN_VARIANT, which are used for 
> its own merry purposes in RECORD_TYPEs.  This is a horrible state of 
> affairs, and so I'd like to clean up the way ObjC stores its own 
> information so that it plays nice(r) with what C and C++ expect.  
> (This work is part of the ongoing ObjC++ integration, BTW, so a prompt 
> response would be appreciated.)
>
> There seem to be several ways of attacking this, but I'd like to ask 
> the powers that be for the preferred approach before actually 
> undertaking it:
> (1)  The additional info required for ObjC RECORD_TYPEs is stored as 
> attributes, which peacefully co-exist with C/C++ attributes in the
>      TYPE_ATTRIBUTES accessor.
> (2)  In addition to a 'struct lang_type *lang_specific' field, each 
> type node also gets a 'struct objc_lang_type *objc_lang_specific' 
> field (set to NULL in plain C and C++ modes).
> (3)  A variation of (2) in which 'struct lang_type' itself (both in C 
> and C++) gets 'struct objc_lang_type *objc_lang_specific' field.
>
> Which of these would be preferable and/or have I left out other 
> possibilities?  It seems that (1) would require least (if any!) 
> changes to existing GCC infrastructure, but the resulting ObjC/ObjC++ 
> compile-time performance would be less than stellar.  Personally, I 
> favor (3).
>
> Please advise,
>
> --Zem
>

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Gabriel Dos Reis]

Ziemowit Laski <zlaski@apple.com> writes:

| On 23 Sep 2004, at 18.36, Zack Weinberg wrote:
| 
| > Ziemowit Laski <zlaski@apple.com> writes:
| >
| >> Please, folks -- this ain't rocket science...
| >
| > You posted your question three hours ago.  Generally it takes at least
| > a day to get an answer out of anyone.
| 
| That's nonsense, and the 'attribute data structure rewrite' thread
| proves it.
| Of course, I can't really force anyone to respond to my questions in a

In particular, if you intend to be rude even in the simplest questions.

-- Gaby

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Gabriel Dos Reis]

Steve Naroff <snaroff@apple.com> writes:

| btw...the terms "ghastly" and "horrible state of affairs seem a bit
| dramatic", eh? Take a deep breath

If you could go and speak with him, that would be much appreciated.

Thanks,

- Gaby

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Zack Weinberg]

Kindly do not include Apple internal mailing lists on the cc: line
when posting to public mailing lists.

Ziemowit Laski <zlaski@apple.com> writes:
> On 23 Sep 2004, at 18.36, Zack Weinberg wrote:
>> Ziemowit Laski <zlaski@apple.com> writes:
>>> Please, folks -- this ain't rocket science...
>>
>> You posted your question three hours ago.  Generally it takes at least
>> a day to get an answer out of anyone.
>
> That's nonsense, and the 'attribute data structure rewrite' thread
> proves it.

Yes, some queries get an immediate response.  Others do not excite as
much interest, or whoever is best suited to comment is away from their
email.  In this case, for instance, I would say that the person best
suited to answer your question is Joseph Myers, but your original
query went out at 11:15 PM in the time zone of the British Isles, and
it is now 3:18 AM there; it is reasonable to assume he has not seen
any of this.

Patience and courtesy get one a lot farther than nagging and shouting.

zw

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[David Edelsohn]

>>>>> Ziemowit Laski writes:

Zem> But I can (and, if necessary, will) hold up
Zem> the release of gcc 4.0 until all of ObjC++ is integrated.

	No you cannot, especially if you continue to use this tone.

David

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]


On 23/09/2004, at 6:19 PM, Ziemowit Laski wrote:

> Please, folks -- this ain't rocket science...
>
> Does any C, C++ and/or global maintainer object to my proceeding with 
> (3) below?

Yes, I object.

> ----
>
> Currently, ObjC does some rather ghastly things with accessors such as 
> TYPE_CONTEXT, TREE_PUBLIC and TYPE_MAIN_VARIANT, which are used for 
> its own merry purposes in RECORD_TYPEs.  This is a horrible state of 
> affairs, and so I'd like to clean up the way ObjC stores its own 
> information so that it plays nice(r) with what C and C++ expect.  
> (This work is part of the ongoing ObjC++ integration, BTW, so a prompt 
> response would be appreciated.)
>
> There seem to be several ways of attacking this, but I'd like to ask 
> the powers that be for the preferred approach before actually 
> undertaking it:
> (1)  The additional info required for ObjC RECORD_TYPEs is stored as 
> attributes, which peacefully co-exist with C/C++ attributes in the
>      TYPE_ATTRIBUTES accessor.
> (2)  In addition to a 'struct lang_type *lang_specific' field, each 
> type node also gets a 'struct objc_lang_type *objc_lang_specific' 
> field (set to NULL in plain C and C++ modes).
> (3)  A variation of (2) in which 'struct lang_type' itself (both in C 
> and C++) gets 'struct objc_lang_type *objc_lang_specific' field.
>
> Which of these would be preferable and/or have I left out other 
> possibilities?  It seems that (1) would require least (if any!) 
> changes to existing GCC infrastructure, but the resulting ObjC/ObjC++ 
> compile-time performance would be less than stellar.  Personally, I 
> favor (3).
>
> Please advise,
>
> --Zem
>

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Zack Weinberg]

Geoffrey Keating <geoffk@apple.com> writes:

> On 23/09/2004, at 6:19 PM, Ziemowit Laski wrote:
>
>> Please, folks -- this ain't rocket science...
>>
>> Does any C, C++ and/or global maintainer object to my proceeding
>> with (3) below?
>
> Yes, I object.

... you could maybe be a little more specific?

zw

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Geoffrey Keating]

[-- Attachment #1: Type: text/plain, Size: 505 bytes --]


On 23/09/2004, at 11:38 PM, Zack Weinberg wrote:

> Geoffrey Keating <geoffk@apple.com> writes:
>
>> On 23/09/2004, at 6:19 PM, Ziemowit Laski wrote:
>>
>>> Please, folks -- this ain't rocket science...
>>>
>>> Does any C, C++ and/or global maintainer object to my proceeding
>>> with (3) below?
>>
>> Yes, I object.
>
> ... you could maybe be a little more specific?

I haven't had time to think about it yet, and that's why I object.  I 
can say that I don't like any of the proposed three solutions.


[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2408 bytes --]

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Joseph S. Myers]

On Thu, 23 Sep 2004, Ziemowit Laski wrote:

> On 23 Sep 2004, at 18.36, Zack Weinberg wrote:
> > I find either (1) or (3) infinitely preferable to (2), and would
> > suggest you consider a (3a) in which the ObjC/ObjC++ front ends
> > enlarge the C/C++ lang_type structures (in much the same way that all
> > these front ends currently build on struct c_common_identifier to
> > create their struct lang_identifier).  This is preferable to (3) if
> > the additional data is small (up to, say, four pointers), or if it
> > needs allocating for practically every RECORD_TYPE.  If it is both
> > large and rarely needed, your original (3) is better.
> 
> The usage patterns would definitely lean towards (3a).  I guess I'll
> investigate
> the c_common_identifier/lang_identifier machinery.

I would concur with the principle here of enlarging the structures only 
for ObjC/ObjC++ rather than making C and C++ carry the extra memory 
consumption cost for fields only used in ObjC/ObjC++.

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
  http://www.srcf.ucam.org/~jsm28/gcc/#c90status - status of C90 for GCC 4.0
    jsm@polyomino.org.uk (personal mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Ziemowit Laski]

On 23 Sep 2004, at 19.27, David Edelsohn wrote:

>>>>>> Ziemowit Laski writes:
>
> Zem> But I can (and, if necessary, will) hold up
> Zem> the release of gcc 4.0 until all of ObjC++ is integrated.
>
> 	No you cannot, especially if you continue to use this tone.

I apologize if I've offended anyone with my impatience; it's just that 
we're
in stage 3 and I do _not_ want to delay gcc 4.0's release (and also 
thought
that others, esp. maintainers, would share this sense of urgency).

--Zem

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Mark Mitchell]

Joseph S. Myers wrote:

>On Thu, 23 Sep 2004, Ziemowit Laski wrote:
>
>  
>
>>On 23 Sep 2004, at 18.36, Zack Weinberg wrote:
>>    
>>
>>>I find either (1) or (3) infinitely preferable to (2), and would
>>>suggest you consider a (3a) in which the ObjC/ObjC++ front ends
>>>enlarge the C/C++ lang_type structures (in much the same way that all
>>>these front ends currently build on struct c_common_identifier to
>>>create their struct lang_identifier).  This is preferable to (3) if
>>>the additional data is small (up to, say, four pointers), or if it
>>>needs allocating for practically every RECORD_TYPE.  If it is both
>>>large and rarely needed, your original (3) is better.
>>>      
>>>
>>The usage patterns would definitely lean towards (3a).  I guess I'll
>>investigate
>>the c_common_identifier/lang_identifier machinery.
>>    
>>
>
>I would concur with the principle here of enlarging the structures only 
>for ObjC/ObjC++ rather than making C and C++ carry the extra memory 
>consumption cost for fields only used in ObjC/ObjC++.
>
Me too. 

That seems like distinctly the way to go, even though I can see that 
there may be some organizational issues in the source code in terms of 
actually implementing that.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Zack Weinberg]

I am not impressed with Geoff's behavior either.  However, the
insulting tone of voice you have taken is a sure-fire way to get me
not to lift a finger to help, and I would not be surprised if other
people react similarly.

zw

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Alex Perez]

On Wed, 17 Nov 2004, Zack Weinberg wrote:

Zack,

> I am not impressed with Geoff's behavior either.  However, the
> insulting tone of voice you have taken is a sure-fire way to get me
> not to lift a finger to help, and I would not be surprised if other
> people react similarly.


My apologies for being rude, but I've personally mailed several people 
off-list about this in the past and was *MUCH* nicer, and it got me 
nowhere. The Apple folks just ignored my inquiries as to what the status 
of this was. This includes Geoff and Zem.

I do not wish to attempt to justify my actions, only give you an insight 
into the fact that my  civil requests have been ignored and I am beginning 
to become slightly alarmed that this is not going to make it into GCC4 as 
a result of certain individuals irresponsible inactions.

Once again, I'm sorry for any fist-clenching I've caused, but I just want 
you to understand that there *WAS* an off-list lead-up to my on-list post, 
and it got me nowhere.

Respectfully,
Alex Perez

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Alex Perez]

Geoffrey Keating wrote:
> 
> On 23/09/2004, at 11:38 PM, Zack Weinberg wrote:
> 
>> Geoffrey Keating <geoffk@apple.com> writes:
>>
>>> On 23/09/2004, at 6:19 PM, Ziemowit Laski wrote:
>>>
>>>> Please, folks -- this ain't rocket science...
>>>>
>>>> Does any C, C++ and/or global maintainer object to my proceeding
>>>> with (3) below?
>>>
>>>
>>> Yes, I object.
>>
>>
>> ... you could maybe be a little more specific?
> 
> 
> I haven't had time to think about it yet, and that's why I object.  I 
> can say that I don't like any of the proposed three solutions.
> 
Well now you have had enough time. What's your excuse now? I know you 
are likely busy, but you probably always are, so welcome to reality. 
Please get up off your arse and either approve or reject these changes. 
It's not too much to ask.

On another note, I'm beginning to wonder if you're intentionally trying 
to obstruct ObjC++ from ever getting into GCC 4.0. If that happens, it 
would, IMHO, be inexcusable, since it's ready /now/. But then again, 
when it really comes down to it, my opinion doesn't matter. I can 
definitively state that I speak for many when I say "we want ObjC++ in 
GCC 4.0, damn it!"

Is it really too much to ask, Mr. Obstructionist Apple GCC dev (Geoff)?

I hope I'm wrong about my suspicions about your 
possibly-questionable-intentions, and if that's the case I urge you to 
PROVE to me, through *ACTIONS* and not just words, that you are not 
trying to stop this from moving foreward.

Disgruntledly (sic) Yours,
Alex Perez

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Zack Weinberg]

Alex Perez <aperez@student.santarosa.edu> writes:
> On Wed, 17 Nov 2004, Zack Weinberg wrote:
>> I am not impressed with Geoff's behavior either.  However, the
>> insulting tone of voice you have taken is a sure-fire way to get me
>> not to lift a finger to help, and I would not be surprised if other
>> people react similarly.
>
> My apologies for being rude, but I've personally mailed several people 
> off-list about this in the past and was *MUCH* nicer, and it got me 
> nowhere. The Apple folks just ignored my inquiries as to what the status 
> of this was. This includes Geoff and Zem.

You were correct to complain on-list.  In fact, this is starting to
look like a matter for the steering committee.  However, you could
have done so in a polite manner.

zw

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Geoffrey Keating]

Alex Perez <aperez@student.santarosa.edu> writes:

> My apologies for being rude, but I've personally mailed several people 
> off-list about this in the past and was *MUCH* nicer, and it got me 
> nowhere. The Apple folks just ignored my inquiries as to what the status 
> of this was. This includes Geoff and Zem.

I don't believe I've recieved any e-mail directly from you on this topic.

Re: PING: Question: Need to store ObjC-specific info in type nodes.

[Alex Perez]

On 18 Nov 2004, Geoffrey Keating wrote:

> Alex Perez <aperez@student.santarosa.edu> writes:
> 
> > My apologies for being rude, but I've personally mailed several people 
> > off-list about this in the past and was *MUCH* nicer, and it got me 
> > nowhere. The Apple folks just ignored my inquiries as to what the status 
> > of this was. This includes Geoff and Zem.
> 
> I don't believe I've recieved any e-mail directly from you on this topic.

Are you absolutely, categorically positive? Is it possible it went into 
your spam folder, never to be seen again? The reason I ask is that I 
recently sent a message to someone and then they told me they'd finally 
found it a week later, crammed in with 50,000 e-mails about how they could 
enlarge their member via 10 different questionable methods.

In any event, I am certain it was sent (about a month or so ago, if I 
recall), but even if you didn't get it that doesn't really excuse your 
inability to find a few free minutes to review this in a timely manner 
over the course of nearly two months. 

Cheers,
Alex Perez