Re: GNUstep core release
On 12 May 2015, at 22:35, Riccardo Mottola riccardo.mott...@libero.it 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 richardfrithmacdon...@gmail.com: On 12 May 2015, at 22:35, Riccardo Mottola riccardo.mott...@libero.it 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
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
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 core release
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. Fred On the road ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release
On 2005-09-13 10:51:18 -0600 Adam Fedor [EMAIL PROTECTED] wrote: I hope to make a new core libraries release this week (sub-minor revision). Assuming I get the time. Also, anyone opposed to making the art back end the default? It's been this way in Startup for a while and there's automatic support for switching back to the x11 backend if the libs are not found. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release
Adam Fedor wrote: On 2005-09-13 10:51:18 -0600 Adam Fedor [EMAIL PROTECTED] wrote: I hope to make a new core libraries release this week (sub-minor revision). Assuming I get the time. Also, anyone opposed to making the art back end the default? It's been this way in Startup for a while and there's automatic support for switching back to the x11 backend if the libs are not found. No, go ahead. I was hoping that I get the cairo backend up and running early enough, so that we could switch to that directly, but this step will take quite a bit longer. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release
No objections here. GJC --- Adam Fedor [EMAIL PROTECTED] wrote: On 2005-09-13 10:51:18 -0600 Adam Fedor [EMAIL PROTECTED] wrote: I hope to make a new core libraries release this week (sub-minor revision). Assuming I get the time. Also, anyone opposed to making the art back end the default? It's been this way in Startup for a while and there's automatic support for switching back to the x11 backend if the libs are not found. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Core release
I hope to make a new core libraries release this week (sub-minor revision). Assuming I get the time. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release, Wed
On Jul 21, 2005, at 4:31 PM, Fred Kiefer wrote: Are you making a release of GUI and back as well? In the last few days I did get the basic cairo backend working again on the changed cairo code. If the back release isn't due in the next few days I'll add that code to CVS, if it's going out soon, I'll wait til after that. Greg asked me to hold Gui until he checks some things. I don't know how long that will be. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release, Wed
All, --- Adam Fedor [EMAIL PROTECTED] wrote: On Jul 21, 2005, at 4:31 PM, Fred Kiefer wrote: Are you making a release of GUI and back as well? In the last few days I did get the basic cairo backend working again on the changed cairo code. If the back release isn't due in the next few days I'll add that code to CVS, if it's going out soon, I'll wait til after that. Greg asked me to hold Gui until he checks some things. I don't know how long that will be. I'm done. I needed to check a change I made to GSWindowTemplate for custom window classes. My tests indicate it's working properly. Please go ahead with the release. Sorry for the delay, but I was at work a little late today. :) Thanks, GJC Gregory John Casamento -- CEO/President Open Logic Corp. (A MD Corp.) ## Maintainer of Gorm (IB Equiv.) for GNUstep. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release, Wed
On Jul 20, 2005, at 6:14 AM, Nicola Pero wrote: I believe the problem is that if you switch to the new -make package, you have to recompile everything from scratch (which I didn't, I reverted to the old gnustep-make as you did). :-( My understanding is that before the change, we linked a tool against -lgnustep-base and -lobjc. gnustep-base itself was not linked against libobjc. After the change, we now link a tool just against -lgnustep-base. gnustep-base itself is now linked to libobjc. So if your gnustep-base was built with the old gnustep-make, but you're using the new gnustep-make to link a tool, libobjc is not linked into gnustep-base (old building style), and will not be linked into the tool (new building style), so you get undefined symbols because libobjc is never linked. Rebuilding only gnustep-base might be enough to fix the problem ... I'd still rebuild everything just to be sure. This makes upgrades a bit cumbersome as you have to upgrade everything, but well that's why we're making a major release I suppose. ;-) Well, I can revert the make part of the patch. It shouldn't be a problem to have lobjc linked multiple times. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release, Wed
This makes upgrades a bit cumbersome as you have to upgrade everything, but well that's why we're making a major release I suppose. ;-) Well, I can revert the make part of the patch. It shouldn't be a problem to have lobjc linked multiple times. My personal suggestion would be to leave the change in, but add a clear explanation (that you need to recompile everything) in the release notes. Eg, taking us (Brainstorm/Opera Telecom) as an example, ordinately rebuilding all software on our live systems when we do our next upgrade should not be too much of a problem ... the important thing is that we know we have to do it! :-) I'm happy with any other solution (including reverting the make part of the patch), I don't think it is particularly important -- the most important thing is having a clear understanding of what is needed to upgrade without problems, and communicating it to users. Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Core release, Wed
I'm mostly satisfied with the libraries now, which is to say, I don't really have any time to make any significant changes. So I'll plan on freezing the release this Wednesday. Unless there are any objections. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release, Wed
On Jul 18, 2005, at 9:59 AM, Nicola Pero wrote: I'm mostly satisfied with the libraries now, which is to say, I don't really have any time to make any significant changes. So I'll plan on freezing the release this Wednesday. Unless there are any objections. The Windows pseudo-framework support needs more polishing ... hopefully I can do some more tomorrow (there are nice patches and suggestions pending -- thanks!). It's probably not a release-critical issue though ? Yes. Do what you can do. I find that things don't really get tested until after I make a release anyway. So it's more than likely I'll have a patch release within a few weeks. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Core release, Wed
Adam Fedor wrote: I'm mostly satisfied with the libraries now, which is to say, I don't really have any time to make any significant changes. So I'll plan on freezing the release this Wednesday. Unless there are any objections. Fine for me. I am still investigating on how best to implement the pattern colours, so this will only go into the release after. Cheers Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
