Re: GNUstep core release
Not a regression but I get a lot of no-brainer warnings during compilation of the base package. For example this will create an error during runtime: NSCalendarDate.m:1778:7: warning: using integer absolute value function 'abs' when argument is of floating point type [-Wabsolute-value] a = abs(d - (_seconds_since_ref + offset(_time_zone, self))); ^ NSCalendarDate.m:1778:7: note: use function 'fabs' instead a = abs(d - (_seconds_since_ref + offset(_time_zone, self))); ^~~ fabs abs will treat the result as int and the result will be defective. Another example is: /usr/GNUstep/Local/Library/Headers/objc/runtime.h:195:13: note: expanded from macro 'NO' # define NO ((BOOL)0) AGSOutput.m:2412:14: warning: expression which evaluates to zero treated as a null pointer constant of type 'NSString *' [-Wnon-literal-null-conversion] return NO; Not a problem during runtime but still an ugly warning. Finally I get this warning with the clang 3.7 compiler: In file included from /usr/include/string.h:25: /usr/include/features.h:148:3: warning: "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" [-W#warnings] # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" this could be handled with __clang_version__ ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep core release
Looks like Richard already fixed the first two issues you reported. The third one is rather in you system include files, nothing we can do about these. It would be great to hear whether there are similar issues in gui or back. Thank you very much, Fred On the road Am 02.05.2015 um 15:06 schrieb Barnaby Jones : > Not a regression but I get a lot of no-brainer warnings during compilation of > the base package. > > For example this will create an error during runtime: > > NSCalendarDate.m:1778:7: warning: using integer absolute value function 'abs' > when argument is of floating point type [-Wabsolute-value] > a = abs(d - (_seconds_since_ref + offset(_time_zone, self))); > ^ > NSCalendarDate.m:1778:7: note: use function 'fabs' instead > a = abs(d - (_seconds_since_ref + offset(_time_zone, self))); > ^~~ > fabs > > abs will treat the result as int and the result will be defective. > > Another example is: > > /usr/GNUstep/Local/Library/Headers/objc/runtime.h:195:13: note: expanded from > macro 'NO' > # define NO ((BOOL)0) > > > AGSOutput.m:2412:14: warning: expression which evaluates to zero treated as a > null pointer constant of type 'NSString *' [-Wnon-literal-null-conversion] > return NO; > > Not a problem during runtime but still an ugly warning. > > Finally I get this warning with the clang 3.7 compiler: > > In file included from /usr/include/string.h:25: > /usr/include/features.h:148:3: warning: "_BSD_SOURCE and _SVID_SOURCE are > deprecated, use _DEFAULT_SOURCE" [-W#warnings] > # warning "_BSD_SOURCE and _SVID_SOURCE are deprecated, use _DEFAULT_SOURCE" > > this could be handled with __clang_version__ > > ___ > Gnustep-dev mailing list > Gnustep-dev@gnu.org > https://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep core release
Hi, Fred Kiefer wrote: Richard and I are planing to do a shared release of the GNUstep core modules (at least base, gui, back, maybe make as well) on May 15th. Could you all please test the current code and report any regressions. Up to this date we should all stop to add new features and restrict us to important bug fixes. I would like to see certain bugs fixed or at least analyzed before a release 1) bug #45032: [base] Bundle not correctly returned for Class in Framework which I'd classify as a blocker 2) bug #45081: gui and back do not pick up compiler setting Confirm my fix and agree if have a warning or error like now 3) bug #43454: Problem with Continuous Spell Checking How serious is this? 4) bug #29730: Build attempt when typing 'make distclean' twice Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep core release
On 12 May 2015, at 22:35, Riccardo Mottola wrote: > > Hi, > > Fred Kiefer wrote: >> Richard and I are planing to do a shared release of the GNUstep core modules >> (at least base, gui, back, maybe make as well) on May 15th. Could you all >> please test the current code and report any regressions. Up to this date we >> should all stop to add new features and restrict us to important bug fixes. > > I would like to see certain bugs fixed or at least analyzed before a release > > 1) bug #45032: [base] Bundle not correctly returned for Class in Framework > which I'd classify as a blocker As long as this is ony on your Solaris system, it's hard to see how to address it (unless you can provide a fix). Is it a regression, or a long term problem? > 2) bug #45081: gui and back do not pick up compiler setting > Confirm my fix and agree if have a warning or error like now I think your fix looks fine, and for the case where an environment variable is used explicitly, I think a warning is sufficient (I'm a power user and am OK with the error; since it only takes 30 seconds to reconfigure/reinstall gnustep-make for a new compiler, but if it really bugs someone else then I don't mind it being a warnign instead). > 3) bug #43454: Problem with Continuous Spell Checking > How serious is this? I'm not familiar with that one ... will try to take a look at it today. > 4) bug #29730: Build attempt when typing 'make distclean' twice I'll definitely get that into base. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep core release
Am 13.05.2015 um 08:09 schrieb Richard Frith-Macdonald : > On 12 May 2015, at 22:35, Riccardo Mottola wrote: >> >> Fred Kiefer wrote: >>> Richard and I are planing to do a shared release of the GNUstep core >>> modules (at least base, gui, back, maybe make as well) on May 15th. Could >>> you all please test the current code and report any regressions. Up to this >>> date we should all stop to add new features and restrict us to important >>> bug fixes. >> >> I would like to see certain bugs fixed or at least analyzed before a release It would be great to resolve all these, but none of it is a show stopper. The release should be done regardless of the state of these bugs. >> >> 1) bug #45032: [base] Bundle not correctly returned for Class in Framework >> which I'd classify as a blocker > > As long as this is ony on your Solaris system, it's hard to see how to > address it (unless you can provide a fix). > Is it a regression, or a long term problem? As far as I know this is no regression. It seems to be related to NSBundle having a wrong view of the file system layout. Sometimes only the first number from the version gets used. Most likely this only affects Solaris as we use different mechanisms on other systems to get the classes when loading a framework. A simple solution could be to check for different directories, removing the parts of the version number one by one. >> 2) bug #45081: gui and back do not pick up compiler setting >> Confirm my fix and agree if have a warning or error like now > > I think your fix looks fine, and for the case where an environment variable > is used explicitly, I think a warning is sufficient (I'm a power user and am > OK with the error; since it only takes 30 seconds to reconfigure/reinstall > gnustep-make for a new compiler, but if it really bugs someone else then I > don't mind it being a warnign instead). I would prefer to have this as a warning in gui and back. On the other hand I personally never had the need to use a special compiler for building these. > >> 3) bug #43454: Problem with Continuous Spell Checking >> How serious is this? > > I'm not familiar with that one ... will try to take a look at it today. This issue is annoying but hard to resolve. Waiting for this might delay the release indefinitely. Do we really want to do this? There are two issues here. One being that the layout system isn't thread safe. To change this requires a lot of rework. The other is, why are we getting there? To reproduce the problem I had to write illegal code. Which part of gui is accessing the layout system from a secondary thread? It might be easier to address this. > >> 4) bug #29730: Build attempt when typing 'make distclean' twice > > I'll definitely get that into base. This is a rather old issue, it would be nice to have it fixed, but again not needed for a release. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
