Re: sync.m
On 1 Mar 2010, at 00:12, Riccardo Mottola wrote: As long of course as core itself doesn't require libobjc-2 feature (which I hope will be never, but that's tough to say). I don't have any plans for core to require anything in libobjc2, per se. There is currently one feature in -base that requires the new ABI; -forwardingTargetForSelector: on NSObject. I wrote a hacky implementation that will try to make this work with the old ABI (using -forwardInvocation:) but it's unreliable. This is quite a new feature on the Apple side, however. It doesn't give any more expressiveness, just a bit more speed. I think the other runtime hooks in NSObject that allow classes and objects to lazily install methods will also only work with libobjc2. Nothing in -base or -gui uses these (well, NSContentAccessingProxy does, but it has fall-back code for when they are not present, so it doesn't /require/ them). If third-party apps do, then that's beyond our control. Depending on them limits you to very recent versions of OS X, but given that people seem to be dropping support for 10.4 already that's possibly not a problem for Mac developers. On 1 Mar 2010, at 06:07, Richard Frith-Macdonald wrote: Nobody is breaking things gratuitously. The c99isms slip in to code simply because all modern compilers support them, and don't warn you that older compilers won't. Most people use them habitually (locality of declaration of variables is particularly good for code readability for instance) and simply won't notice that they have used them. Additionally, a load of C99 features (e.g. VLAs, which GNUstep has used for ages) are implemented as extensions by GCC 2.95. Without access to it, it's difficult to keep track of exactly which subset of C99 will work with any given compiler version. GCC is terrible at documenting when features appeared; they expect everyone to use the latest version. David -- Sent from my Cray X1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
Just for the record, I have nothing really to add to either David or Richard's comments since both of them sum up my feelings on the subject very succinctly. We should not sacrifice new features or readability for the sake of holding on to older architectures and compilers. Also, the use of non-c99 standards does hinder contributions since we constantly expect people who don't have access to c99 based compilers to change their code to conform to c89. GC On Mon, Mar 1, 2010 at 7:44 AM, David Chisnall thera...@sucs.org wrote: On 1 Mar 2010, at 00:12, Riccardo Mottola wrote: As long of course as core itself doesn't require libobjc-2 feature (which I hope will be never, but that's tough to say). I don't have any plans for core to require anything in libobjc2, per se. There is currently one feature in -base that requires the new ABI; -forwardingTargetForSelector: on NSObject. I wrote a hacky implementation that will try to make this work with the old ABI (using -forwardInvocation:) but it's unreliable. This is quite a new feature on the Apple side, however. It doesn't give any more expressiveness, just a bit more speed. I think the other runtime hooks in NSObject that allow classes and objects to lazily install methods will also only work with libobjc2. Nothing in -base or -gui uses these (well, NSContentAccessingProxy does, but it has fall-back code for when they are not present, so it doesn't /require/ them). If third-party apps do, then that's beyond our control. Depending on them limits you to very recent versions of OS X, but given that people seem to be dropping support for 10.4 already that's possibly not a problem for Mac developers. On 1 Mar 2010, at 06:07, Richard Frith-Macdonald wrote: Nobody is breaking things gratuitously. The c99isms slip in to code simply because all modern compilers support them, and don't warn you that older compilers won't. Most people use them habitually (locality of declaration of variables is particularly good for code readability for instance) and simply won't notice that they have used them. Additionally, a load of C99 features (e.g. VLAs, which GNUstep has used for ages) are implemented as extensions by GCC 2.95. Without access to it, it's difficult to keep track of exactly which subset of C99 will work with any given compiler version. GCC is terrible at documenting when features appeared; they expect everyone to use the latest version. David -- Sent from my Cray X1 ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev -- Gregory Casamento - GNUstep Lead/Principal Consultant, OLC, Inc. yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: sync.m
We should not sacrifice new features or readability for the sake of
holding on to older architectures and compilers.
Also, the use of non-c99 standards does hinder contributions since we
constantly expect people who don't have access to c99 based compilers
to change their code to conform to c89.
I think we should have a clear, explicit and unemotional support/
compatibility strategy. :-)
As GCC 2.95.3 was released in March 16, 2001, it may make sense to no
longer support it.
Or maybe it does. I vote for supporting it.
Anyway the question really is - what is the oldest GCC that we support
if it's not 2.95.3 ?
3.0.4 (released February 20, 2002) ?
Just mentioning c99 doesn't seem to help that much since IIRC no
version of GCC
actually implements all of c99 anyway. I actually am not really sure
what C99 features,
added after 2.95, we really need.
Nobody is breaking things gratuitously. The c99isms slip in to
code simply because all modern compilers support them, and don't
warn you that older compilers won't. Most people use them
habitually (locality of declaration of variables is particularly
good for code readability for instance) and simply won't notice
that they have used them.
We can use -Wdeclaration-after-statement to get a post-2.95 GCC warn
you when you locally declare variables without starting a { } block.
Really not a problem - it's easy enough to add it to gnustep-base and
gnustep-gui.
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
I just recompiled Gorm and it looks different here :-) As this is also on a 64bit system the main difference I see is the cairo version. Could you please try a different backend to confirm that it is the cairo backend that causes this behaviour. There are a few places in CarioGState where we differentiate based on the cairo version number. Perhaps a few of these checks are off? I know that GNUstep worked with all the cairo releases that were available for OpenSuse (I had to get it working as I use this backend for years now), but there may be cairo releases where extra bugs need to be worked around. If it turns out, the problem isn't backend relate, it will be much hard to pin it down Am 01.03.2010 00:03, schrieb ici...@mail.cg.tuwien.ac.at: It's my own application which shows this behaviour. I do not have a theme enabled, I am using the cairo backend. Everything is built from current svn trunk. Gorm shows the same broken behaviour on my machine, screenshot is attached. I am on Ubuntu 8.04 AMD64, cairo version is 1.6.0. Thanks TOM Zitat von Fred Kiefer fredkie...@gmx.de: I just tried to reproduce this behaviour and failed to. On which application are you seeing this and probably more important, which GNUstep backend are you using? Do you have a theme enable? Am 27.02.2010 18:54, schrieb ici...@mail.cg.tuwien.ac.at: Looks like NSTabView in trunk is currently buggy. I attached a screenshot to this message. Gorm from svn trunk displays it the same way. Tell me if you need further information. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
Hi! I did a test with the art backend, same result. I set a breakpoint in [ARTContext initializeBackend] to be sure it is actually used. Where is the code located that is responsible for drawing the NSTabView's header? Thanks TOM Zitat von Fred Kiefer fredkie...@gmx.de: I just recompiled Gorm and it looks different here :-) As this is also on a 64bit system the main difference I see is the cairo version. Could you please try a different backend to confirm that it is the cairo backend that causes this behaviour. There are a few places in CarioGState where we differentiate based on the cairo version number. Perhaps a few of these checks are off? I know that GNUstep worked with all the cairo releases that were available for OpenSuse (I had to get it working as I use this backend for years now), but there may be cairo releases where extra bugs need to be worked around. If it turns out, the problem isn't backend relate, it will be much hard to pin it down Am 01.03.2010 00:03, schrieb ici...@mail.cg.tuwien.ac.at: It's my own application which shows this behaviour. I do not have a theme enabled, I am using the cairo backend. Everything is built from current svn trunk. Gorm shows the same broken behaviour on my machine, screenshot is attached. I am on Ubuntu 8.04 AMD64, cairo version is 1.6.0. Thanks TOM Zitat von Fred Kiefer fredkie...@gmx.de: I just tried to reproduce this behaviour and failed to. On which application are you seeing this and probably more important, which GNUstep backend are you using? Do you have a theme enable? Am 27.02.2010 18:54, schrieb ici...@mail.cg.tuwien.ac.at: Looks like NSTabView in trunk is currently buggy. I attached a screenshot to this message. Gorm from svn trunk displays it the same way. Tell me if you need further information. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
[NSTabView drawRect:] Am 01.03.2010 22:39, schrieb ici...@mail.cg.tuwien.ac.at: Hi! I did a test with the art backend, same result. I set a breakpoint in [ARTContext initializeBackend] to be sure it is actually used. Where is the code located that is responsible for drawing the NSTabView's header? Thanks TOM Zitat von Fred Kiefer fredkie...@gmx.de: I just recompiled Gorm and it looks different here :-) As this is also on a 64bit system the main difference I see is the cairo version. Could you please try a different backend to confirm that it is the cairo backend that causes this behaviour. There are a few places in CarioGState where we differentiate based on the cairo version number. Perhaps a few of these checks are off? I know that GNUstep worked with all the cairo releases that were available for OpenSuse (I had to get it working as I use this backend for years now), but there may be cairo releases where extra bugs need to be worked around. If it turns out, the problem isn't backend relate, it will be much hard to pin it down Am 01.03.2010 00:03, schrieb ici...@mail.cg.tuwien.ac.at: It's my own application which shows this behaviour. I do not have a theme enabled, I am using the cairo backend. Everything is built from current svn trunk. Gorm shows the same broken behaviour on my machine, screenshot is attached. I am on Ubuntu 8.04 AMD64, cairo version is 1.6.0. Thanks TOM Zitat von Fred Kiefer fredkie...@gmx.de: I just tried to reproduce this behaviour and failed to. On which application are you seeing this and probably more important, which GNUstep backend are you using? Do you have a theme enable? Am 27.02.2010 18:54, schrieb ici...@mail.cg.tuwien.ac.at: Looks like NSTabView in trunk is currently buggy. I attached a screenshot to this message. Gorm from svn trunk displays it the same way. Tell me if you need further information. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSTabView
Hi, just for the record, I'm on Freebsd, x86-ia32, cairo 1.8.8.1 and I cannot reproduce your problem, cairo works for me. Riccardo ici...@mail.cg.tuwien.ac.at wrote: It's my own application which shows this behaviour. I do not have a theme enabled, I am using the cairo backend. Everything is built from current svn trunk. Gorm shows the same broken behaviour on my machine, screenshot is attached. I am on Ubuntu 8.04 AMD64, cairo version is 1.6.0. Thanks TOM ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
