Re: problems compiling NSAnimation.m
On 9 May 2007, at 17:53, Xavier Glattard wrote:
Riccardo multix at ngi.it writes:
#define _NSANIMATION_LOCK \
BOOL __gs_isLocked = NO; \
if (_isThreaded) \
{ \
__gs_isLocked = YES;\
NSDebugFLLog( at NSAnimationLock,\
at % at LOCK % at ,self,[NSThread
currentThread]);\
[_isAnimatingLock lock];\
}
it causes a hidden c99-ism everywhere. If the definition of
I wrote this stuff, so i guess i could help ;-)
I dont know if this can be avoided :
This is coming from a position of not having been tested nor even
thought through properly, but how about:
#define _NSANIMATION_LOCK \
{ BOOL __gs_isLocked = NO; \
//... \
}
? That should remove the C99-esque behaviour - I don't _think_ it
makes the macro any less usable than it already was but as I say, I
haven't studied its use much.
Graham.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On May 8, 2007, at 11:14 PM, Riccardo wrote:
Hi,
trying to compile NSAnimation on older compilers is a nightmare
(like gcc 2.95). I fixed some trivial stuff, but then stopped: the
main problem is the _NSANIMATION_LOCK macro. Since this macro
defines a variable in it,
#define _NSANIMATION_LOCK \
BOOL __gs_isLocked = NO; \
if (_isThreaded) \
{ \
__gs_isLocked = YES;\
NSDebugFLLog(@NSAnimationLock,\
@%@ LOCK %@,self,[NSThread currentThread]);\
[_isAnimatingLock lock];\
}
it causes a hidden c99-ism everywhere. If the definition of
__gs_isLocked inside the macron can be avoided or the macroitself
can be avoided, I think the code would be cleaner.
This looks pretty bad, not only because it doesn't compile with GCC
2.95, but also because that variable defined in the middle of nowhere
is very ugly ... unclear
scope (what happens if you have two _NSANIMATION_LOCK in sequence ?
is the same variable being used or different variables ?) ... ;-)
Is there a flag we can pass to ask GCC to refuse c99-isms ? There
must be one. Shall we add this to the core library makefiles ? That
way we are
more positive that the code should compile with 2.95 because nobody
will be able to commit c99-isms without breaking compilation with all
versions
of GCC. :-)
Thanks
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 10 May 2007, at 12:35, Nicola Pero wrote: Is there a flag we can pass to ask GCC to refuse c99-isms ? There must be one. -std=c89 or -std=gnu89 depending on whether we want to permit GNU C extensions. Cheers, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 10 May 2007, at 12:35, Nicola Pero wrote:
On May 8, 2007, at 11:14 PM, Riccardo wrote:
Hi,
trying to compile NSAnimation on older compilers is a nightmare
(like gcc 2.95). I fixed some trivial stuff, but then stopped: the
main problem is the _NSANIMATION_LOCK macro. Since this macro
defines a variable in it,
#define _NSANIMATION_LOCK \
BOOL __gs_isLocked = NO; \
if (_isThreaded) \
{ \
__gs_isLocked = YES;\
NSDebugFLLog(@NSAnimationLock,\
@%@ LOCK %@,self,[NSThread currentThread]);\
[_isAnimatingLock lock];\
}
it causes a hidden c99-ism everywhere. If the definition of
__gs_isLocked inside the macron can be avoided or the macroitself
can be avoided, I think the code would be cleaner.
This looks pretty bad, not only because it doesn't compile with GCC
2.95, but also because that variable defined in the middle of
nowhere is very ugly ... unclear
scope (what happens if you have two _NSANIMATION_LOCK in
sequence ? is the same variable being used or different
variables ?) ... ;-)
I fixed this to make __gs_isLocked an ivar rather than declaring it
locally (which was pretty suboptimal). I also fixed a bug in the
unlock macro (it was setting the lag to the wrong value), and added
assertions to check that the macro is not misused.
Is there a flag we can pass to ask GCC to refuse c99-isms ? There
must be one.
Not that I know of ... and I did look for it once before.
Shall we add this to the core library makefiles ? That way we are
more positive that the code should compile with 2.95 because nobody
will be able to commit c99-isms without breaking compilation with
all versions
of GCC. :-)
I'd certainly like such a flag to be added if you can find one.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 10 May 2007, at 12:41, Graham J Lee wrote: On 10 May 2007, at 12:35, Nicola Pero wrote: Is there a flag we can pass to ask GCC to refuse c99-isms ? There must be one. -std=c89 or -std=gnu89 depending on whether we want to permit GNU C extensions. I don't believe those work for objc code ... I remember I looked for something that would do the job some time ago, and failed to find anything. I'm fairly sure this was one of the options I tried. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Fwd: problems compiling NSAnimation.m
Sorry, forgot to put the mailing list in Cc: Thanks Is there a flag we can pass to ask GCC to refuse c99-isms ? There must be one. -std=c89 or -std=gnu89 depending on whether we want to permit GNU C extensions. Nicola answered: Actually, they seem to work -- the problem is that -std=gnu89 is already the standard, but was changed in GCC 3.0 to allow declarations of variables in the middle of code (which are, in this context, a 'GNU extension' borrowed from c99). I think what we want is -Wdeclaration-after-statement The problems are: * not sure if that flag is available with GCC 2.95 -- need to check what happens if you use it with GCC 2.95 * it generates a warning, not an error Anyway, I'll add that flag to the core libs. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 10 May 2007, at 13:44, Nicola Pero wrote: Sorry, forgot to put the mailing list in Cc: Thanks Is there a flag we can pass to ask GCC to refuse c99-isms ? There must be one. -std=c89 or -std=gnu89 depending on whether we want to permit GNU C extensions. Nicola answered: Actually, they seem to work -- the problem is that -std=gnu89 is already the standard, but was changed in GCC 3.0 to allow declarations of variables in the middle of code (which are, in this context, a 'GNU extension' borrowed from c99). I think what we want is -Wdeclaration-after-statement The problems are: * not sure if that flag is available with GCC 2.95 -- need to check what happens if you use it with GCC 2.95 * it generates a warning, not an error Anyway, I'll add that flag to the core libs. Thanks How about -Werror? That might encourage people to clean up any existing mess too ;-). OTOH it might be a scary amount of mess... Cheers, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 10 May 2007, at 14:57, Xavier Glattard wrote: Richard Frith-Macdonald richard at tiptree.demon.co.uk writes: On 10 May 2007, at 12:35, Nicola Pero wrote: (...) This looks pretty bad, not only because it doesn't compile with GCC 2.95, but also because that variable defined in the middle of nowhere is very ugly ... unclear scope (what happens if you have two _NSANIMATION_LOCK in sequence ? is the same variable being used or different variables ?) ... This macro is used as a macro : to repeat again and again the same piece of code. It only has to be used in this class. If you have two _NSANIMATION_LOCK then you have made an error : would you code two [NSThread -lock] in sequence ? You might ... if one method locks then calls another method which also locks. Of course, if this is possible then the lock needs to be a recursive one. I fixed this to make __gs_isLocked an ivar rather than declaring it locally (which was pretty suboptimal). I also fixed a bug in the unlock macro (it was setting the lag to the wrong value), and added assertions to check that the macro is not misused. Bad. If __gs_locked is needed (and as i said i think it is not : i made an error) then it must be declared in all methods. If __gs_isLocked is an ivar, its value can be changed in another method then the [unlock] will never be called. Sure, but similarly if it's a local variable its value can be incorrectly changed within a method or function where it is declared. An ivar already exists: _isThreaded. But that doesn't record the same thing. The __gs_locked boolean records whether the lock is locked, not whether the animation is threaded. However, quite likely you are correct and it's not needed and the whole thing can be removed ... I only looked at the code enough to fix it to compile and manage locking correctly, not enough to optimise/restructure. If/when this code is restructured, it would IMO be good to replace all the ivars with a single pointer to a private structure so that future changes to ivar layout can be done without breaking binary compatibility between releases. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
Richard Frith-Macdonald richard at tiptree.demon.co.uk writes: On 10 May 2007, at 14:57, Xavier Glattard wrote: Richard Frith-Macdonald richard at tiptree.demon.co.uk writes: (...) This macro is used as a macro : to repeat again and again the same piece of code. It only has to be used in this class. If you have two _NSANIMATION_LOCK then you have made an error : would you code two [NSThread -lock] in sequence ? You might ... if one method locks then calls another method which also locks. Of course, if this is possible then the lock needs to be a recursive one. We are talking of two _NSANIMATION_LOCK in sequence _in_the_same_method_. As it is present in (near) all methods IT IS called many time in sequence ! I fixed this to make __gs_isLocked an ivar rather than declaring it locally (which was pretty suboptimal). I also fixed a bug in the unlock macro (it was setting the lag to the wrong value), and added assertions to check that the macro is not misused. Bad. If __gs_locked is needed (and as i said i think it is not : i made an error) then it must be declared in all methods. If __gs_isLocked is an ivar, its value can be changed in another method then the [unlock] will never be called. Sure, but similarly if it's a local variable its value can be incorrectly changed within a method or function where it is declared. If it is then you made an other programming error... ;-) Its name is prefixed by an underscore (and by 'gs'!) so it shouldn't be used by anyone. Moreover an ivar is more easier to be incorrectly changed... in an other method or even in a child class! An ivar already exists: _isThreaded. But that doesn't record the same thing. The __gs_locked boolean records whether the lock is locked, not whether the animation is threaded. I agree : _gs_isLocked records whether the _local_ lock is locked. So it has to be a _local_ variable. _gs_isLocked as an ivar is an error. (...) I only looked at the code enough to fix it to compile and manage locking correctly (...) Did you run GSTest ? Regards Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 10 May 2007, at 15:28, Xavier Glattard wrote: Richard Frith-Macdonald richard at tiptree.demon.co.uk writes: On 10 May 2007, at 14:57, Xavier Glattard wrote: Richard Frith-Macdonald richard at tiptree.demon.co.uk writes: I fixed this to make __gs_isLocked an ivar rather than declaring it locally (which was pretty suboptimal). I also fixed a bug in the unlock macro (it was setting the lag to the wrong value), and added assertions to check that the macro is not misused. Bad. If __gs_locked is needed (and as i said i think it is not : i made an error) then it must be declared in all methods. If __gs_isLocked is an ivar, its value can be changed in another method then the [unlock] will never be called. Sure, but similarly if it's a local variable its value can be incorrectly changed within a method or function where it is declared. If it is then you made an other programming error... ;-) Its name is prefixed by an underscore (and by 'gs'!) so it shouldn't be used by anyone. Moreover an ivar is more easier to be incorrectly changed... in an other method or even in a child class! That's one of the reasons I suggested wrapping the whole macro in braces - the BOOL then becomes a local variable to the macro - reduces the chance of accidentally changing it by restricting the scope to only where it's used. Cheers, Graham. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 10 May 2007, at 15:37, Graham J Lee wrote: On 10 May 2007, at 15:28, Xavier Glattard wrote: Richard Frith-Macdonald richard at tiptree.demon.co.uk writes: On 10 May 2007, at 14:57, Xavier Glattard wrote: Richard Frith-Macdonald richard at tiptree.demon.co.uk writes: I fixed this to make __gs_isLocked an ivar rather than declaring it locally (which was pretty suboptimal). I also fixed a bug in the unlock macro (it was setting the lag to the wrong value), and added assertions to check that the macro is not misused. Bad. If __gs_locked is needed (and as i said i think it is not : i made an error) then it must be declared in all methods. If __gs_isLocked is an ivar, its value can be changed in another method then the [unlock] will never be called. Sure, but similarly if it's a local variable its value can be incorrectly changed within a method or function where it is declared. If it is then you made an other programming error... ;-) Its name is prefixed by an underscore (and by 'gs'!) so it shouldn't be used by anyone. Moreover an ivar is more easier to be incorrectly changed... in an other method or even in a child class! That's one of the reasons I suggested wrapping the whole macro in braces - the BOOL then becomes a local variable to the macro - reduces the chance of accidentally changing it by restricting the scope to only where it's used. If you did that the variable would be out of scope when you tried to use it in the unlock macro. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
On 10 May 2007, at 15:28, Xavier Glattard wrote: I fixed this to make __gs_isLocked an ivar rather than declaring it locally (which was pretty suboptimal). I also fixed a bug in the unlock macro (it was setting the lag to the wrong value), and added assertions to check that the macro is not misused. Bad. If __gs_locked is needed (and as i said i think it is not : i made an error) then it must be declared in all methods. If __gs_isLocked is an ivar, its value can be changed in another method then the [unlock] will never be called. Sure, but similarly if it's a local variable its value can be incorrectly changed within a method or function where it is declared. If it is then you made an other programming error... ;-) Its name is prefixed by an underscore (and by 'gs'!) so it shouldn't be used by anyone. Moreover an ivar is more easier to be incorrectly changed... in an other method or even in a child class! You are missing my point ... the variable is not used by any other code! You can't prevent it being used if someone wants to introduce a bug, but there is no reason why anyone should do that. Making it an ivar *fixes* the code to work with an older compiler An ivar already exists: _isThreaded. But that doesn't record the same thing. The __gs_locked boolean records whether the lock is locked, not whether the animation is threaded. I agree : _gs_isLocked records whether the _local_ lock is locked. So it has to be a _local_ variable. _gs_isLocked as an ivar is an error. Actually that's not correct ... the lock is an ivar and is *not* local to the method, so as the lock can be modified by any method, the variable to record its state similarly needs to be modified in any method where the lock is modified. (...) I only looked at the code enough to fix it to compile and manage locking correctly (...) Did you run GSTest ? Nope. Does that now test animations? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
Richard Frith-Macdonald richard at tiptree.demon.co.uk writes: (...) Making it an ivar *fixes* the code to work with an older compiler Making it an ivar breaks the class in thread mode. ;-) (...) Actually that's not correct ... the lock is an ivar and is *not* local to the method, so as the lock can be modified by any method, the variable to record its state similarly needs to be modified in any method where the lock is modified. The NSRecursiveLock (did you note the lock is recursive ?) is an ivar, but the [-lock] ans [-unlock] calls are local to the method. Each method that calls lock must call unlock. __gs_isLocked records if [lock] has been called : if it is then [unlock] is called before the method returns. If an other method is called before the [unlock] then your __gs_isLocked ivar is reset (in the _NSANIMATION_UNLOCK of the called method) and [unlock] is never called. (...) Did you run GSTest ? Nope. Does that now test animations? Yep. Two demos (not really 'tests'). And they run in threaded mode by default. Xavier ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
This looks pretty bad, not only because it doesn't compile with GCC 2.95, but also because that variable defined in the middle of nowhere is very ugly ... unclear scope (what happens if you have two _NSANIMATION_LOCK in sequence ? is the same variable being used or different variables ?) ... This macro is used as a macro : to repeat again and again the same piece of code. It only has to be used in this class. If you have two _NSANIMATION_LOCK then you have made an error : would you code two [NSThread -lock] in sequence ? What I mean is that I find the code /* some code here */ int c = 0; /* do something with c */ int c = 0; /* do something with c */ very confusing, because when the second declaration of c is reached, you need to be a C standard lawyer to know what happens ;-) Ie, will it keep the same value that it had ? will the second declaration shadow the first one ? will the second assignment to c happen or not ? What about adding a macro _NSANIMATION_SETUP that defines your local variable (and does nothing else) - and that you put at the beginning of every method -, and then have _NSANIMATION_LOCK that only checks/assigns the variable ? ie, the equivalent of #define _NSANIMATION_SETUP \ int c = 0; #define _NSANIMATION_LOCK \ /* do something with c */ Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: problems compiling NSAnimation.m
Nicola Pero nicola.pero at meta-innovation.com writes: (...) very confusing, because when the second declaration of c is reached, you need to be a C standard lawyer to know what happens Yes, but only a C-riminal would do such a thing ;-) (...) What about adding a macro _NSANIMATION_SETUP That sounds good and elegant. But IMHO it would be far easier to DELETE any reference to __gs_isLocked and only test _isThreaded. Unless someone can explain why i wrote such a piece of code... ;-) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
gui linking problem
Hi, after the fixes of NSAnimation and some other small stuff I fixed myself, gui compilation on my older box fails with: Compiling file set_show_service.m ... Linking tool set_show_service ... /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NSProcessInfo' are not defined /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NXConstantString' are not defined /usr/bin/ld: warning: type and size of dynamic symbol `__objc_class_name_NSAutoreleasePool' are not defined ../Source/./obj/libgnustep-gui.so: undefined reference to `png_sizeof' collect2: ld returned 1 exit status make[2]: *** [obj/set_show_service] Error 1 make[1]: *** [set_show_service.all.tool.variables] Error 2 make[1]: Leaving directory `/home/multix/gnt/gnustep-gui-0.13.0/Tools' make: *** [internal-all] Error 2 [EMAIL PROTECTED] gnustep-gui-0. is png_sizeof something that hsould be provided by my png library? I still have installed: libpng-devel-1.2.5-1 libpng-1.2.5-1 which used to be enough up to the past release I compiled... I thought that versions differing by minor release numbers were all OK. is an update mandatory or is something else wrong? -Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
