Re: GWorkspace crash
Riccardo Mottola: the recent changes, make GWorkspace crash or hang. I get a crash on FreeBSD if I try to close one of the viewer windows: Curiously, I stumbled over the same crash just yesterday, which happens because a dangling delegate pointer is left in the viewer window when it is closed. I've just committed a change that fixes this issue. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi, yes I find it due, we spoke about that before Fosdem indeed! This time we should really stabilize ad decide that for a period of a fortnight (or longer if deemed needed) where only bugfixes are commited! Not changes to the runtime or other far-reaching things. Also, fixes may produce bugs and need to be refixed. The changes introduced were extremely huge and their effect is just now stabilizing. Currently, the core systems compiles on most platforms I have available, spanning from gcc 2.95 to gcc 4.4 and from sparc to MIPS. Recently I even got GNU/Hurd compiling! Linux, FreeBSD, OpenBSD, Windows compile. However, there are bugs and problems. For example, I'm unable to start anything on Hurd because gdomap/gdnc seem to have problems. GWorkspace crashes everywhere (which it didn't up to a month ago about). Also GWorkspace now has strange problems. I think it would be also good to check our bug list and see if a couple of those bugs should be fixed with the release. Given the recent surge of interest in Windows, I hope that Adam will also prepare a Windows release (I would suggest based on gcc/objc1, but possibly supporting clang/objc2 too). And let's make that a good release! After this release, I'd like Richard release a new version of GSWS and I will release an application based on it to the public. So let's check the details! Riccardo Fred Kiefer wrote: Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, or so it seems from the outside and gui had to play catch up. Then I toyed around with the NIB loading and broke a few things. Now things are rather stable again and we should come back to our original plan. For gui this would be an intermediate release not the 1.0 release I am hoping to see later this year. What still needs to be done in gui is finishing the switch to #import, moving on to non fragile ivars will happen later. I first want to see the results base gets with its approach to that topic. Adam, could you once more take up the task of releasing GNUstep? We should give it another week or two so that people can complain about existing bugs that need to be fixed before the release. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Fred Kiefer wrote: Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, or so it seems from the outside and gui had to play catch up. Then I toyed around with the NIB loading and broke a few things. Now things are rather stable again and we should come back to our original plan. For gui this would be an intermediate release not the 1.0 release I am hoping to see later this year. What still needs to be done in gui is finishing the switch to #import, moving on to non fragile ivars will happen later. I first want to see the results base gets with its approach to that topic. Adam, could you once more take up the task of releasing GNUstep? We should give it another week or two so that people can complain about existing bugs that need to be fixed before the release. Well, just for a start: Rereading the Apple docs, I've noticed a (long-standing) incompatibility in the nib loading code. When one of the nib loading functions is called with an external name table and this dictionary contains the NS(Nib)TopLevelObjects key, GNUstep passes ownership of the top-level objects to the sender. However, this is not the case in Cocoa. Have a look at the Cocoa Resource Programming Guide and in particular the section Loading Nib Files into Your Program Programmatically (http://developer.apple.com/mac/library/ documentation/cocoa/Conceptual/LoadingResources/CocoaNibs/ CocoaNibs.html#//apple_ref/doc/uid/1051i-CH4-SW24). Try the example code from Listing 2-4 with your favorite nib/gorm file and you will observe a crash in GNUstep because the top-level objects are released once too often. While testing this, I've also noticed that NSNib.h does not define the string constants NSNibOwner and NSNibTopLevelObjects, which were introduced together with NSNib in 10.3. Please note that Apple uses the values @NSOwner and @NSTopLevelObjects for these constants for backward compatibility. This is documented in Apple's NSNib.h header file, but I couldn't find it in the online docs. I guess following Apple's approach would simplify the nib loading code in a few places. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
On 26 Mar 2010, at 19:55, Fred Kiefer wrote: What still needs to be done in gui is finishing the switch to #import, moving on to non fragile ivars will happen later. I first want to see the results base gets with its approach to that topic. I made some small changes in -gui last night that remove the uses of @defs, making it compatible with the non-fragile ABI. You can now compile -base and -gui with the non-fragile ABI. I've not tried -back yet, but I think it should work too. David -- Sent from my STANTEC-ZEBRA ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [PATCH] A NSNetService implementation using Avahi
On Fri, Mar 26, 2010 at 09:26:14AM +0100, Fred Kiefer wrote: I only had a short look at this patch and was a bit surprised to see how little these two implementations share. In a normal class cluster you would expect that most of the code is in the common super class and only the primitive methods get implemented separately. What was the reason for doing it differently here? Even the delegate handling methods are duplicated, with the mDNS ones having an additional tracing call. Apart from that your patch makes perfectly sense to me. Fred PS: You seem to be using tabs to indent your code. Spaces (two of them actually) are prefered. All ammended (including indentation) and available from the locations previously announced [0,1]. But I understand you won't be wanting to apply this until after the proposed release… Cheers, Niels -- [0] http://www.halbordnung.de/~thebeing/gnustep/NSNetServices+avahi.patch [1] http://review.etoileos.com/r/137/ signature.asc Description: Digital signature ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi Fred, Le 26 mars 2010 à 20:55, Fred Kiefer a écrit : Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, or so it seems from the outside and gui had to play catch up. Then I toyed around with the NIB loading and broke a few things. Now things are rather stable again and we should come back to our original plan. For gui this would be an intermediate release not the 1.0 release I am hoping to see later this year. What still needs to be done in gui is finishing the switch to #import, moving on to non fragile ivars will happen later. I first want to see the results base gets with its approach to that topic. Adam, could you once more take up the task of releasing GNUstep? We should give it another week or two so that people can complain about existing bugs that need to be fixed before the release. The bug I really want to fix is #27782 I worked on a better patch before the FOSDEM and was planning to submit it this month, but I got sidetracked. Looks like I have to hurry a bit now. Quentin. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
I agree we should release soon. There are a few bugs I would like to correct on the Windows side of things before we release. Also, I want to make sure the nib/gorm changes have completely stabilized prior to the release. Additionally, for the Windows packages the default theme should be the WinUXTheme and not the NeXT theme on that system. GC On Sat, Mar 27, 2010 at 5:45 PM, Quentin Mathé qma...@gmail.com wrote: Hi Fred, Le 26 mars 2010 à 20:55, Fred Kiefer a écrit : Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, or so it seems from the outside and gui had to play catch up. Then I toyed around with the NIB loading and broke a few things. Now things are rather stable again and we should come back to our original plan. For gui this would be an intermediate release not the 1.0 release I am hoping to see later this year. What still needs to be done in gui is finishing the switch to #import, moving on to non fragile ivars will happen later. I first want to see the results base gets with its approach to that topic. Adam, could you once more take up the task of releasing GNUstep? We should give it another week or two so that people can complain about existing bugs that need to be fixed before the release. The bug I really want to fix is #27782 I worked on a better patch before the FOSDEM and was planning to submit it this month, but I got sidetracked. Looks like I have to hurry a bit now. Quentin. ___ 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: Next GNUstep release?
On 27 Mar 2010, at 21:57, Gregory Casamento wrote: I agree we should release soon. There are a few bugs I would like to correct on the Windows side of things before we release. Also, I want to make sure the nib/gorm changes have completely stabilized prior to the release. Possibly we should have a feature freeze in svn for a couple of weeks, for testing and bug fixing prior to the release? Additionally, for the Windows packages the default theme should be the WinUXTheme and not the NeXT theme on that system. Completely agree. David -- Sent from my brain ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
gcc version and declaration-after-statement
Hi, what gcc version is -Wdeclaration-after-statement enabled for? I know it works for the gcc 4. series, it doesn't for 2.95. On one of my lesser-used computers I have gcc 3.3.2 and it is not supported. Could it please be disabled? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi, Additionally, for the Windows packages the default theme should be the WinUXTheme and not the NeXT theme on that system. Completely agree. I heartily disagree, even if I am the one that started working on it after the hiatus of Christopher and Fred! I understand all the pressure Greg wants, but I still think it is not ready. The apps he thinks about work, but not the one I want to release, one of which I want to release well doesn't. If the application doesn't come up with a main window, the menus have troubles, or if it doesn't open an untitled document (same problem). Several others apps do work, but are very ugly. Possible solutions were discussed, but none implemented yet. Also ideas about directly with the app plist were put on the table. Right now it is too early, I propose to ship it together with system preferences, easy to enable, but not yet default. Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Agreed. On Sat, Mar 27, 2010 at 6:02 PM, David Chisnall thera...@sucs.org wrote: On 27 Mar 2010, at 21:57, Gregory Casamento wrote: I agree we should release soon. There are a few bugs I would like to correct on the Windows side of things before we release. Also, I want to make sure the nib/gorm changes have completely stabilized prior to the release. Possibly we should have a feature freeze in svn for a couple of weeks, for testing and bug fixing prior to the release? Additionally, for the Windows packages the default theme should be the WinUXTheme and not the NeXT theme on that system. Completely agree. David -- Sent from my brain -- 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: Next GNUstep release?
On Mar 26, 2010, at 1:55 PM, Fred Kiefer wrote: Adam, could you once more take up the task of releasing GNUstep? We should give it another week or two so that people can complain about existing bugs that need to be fixed before the release. I'll help make a release whenever it's ready.___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Riccardo, On Sat, Mar 27, 2010 at 6:33 PM, Riccardo Mottola mul...@ngi.it wrote: I heartily disagree, even if I am the one that started working on it after the hiatus of Christopher and Fred! I believe it's fair to say that I've been improving and working on it quite a bit since you and Fred did the initial work. I understand all the pressure Greg wants, but I still think it is not ready. The apps he thinks about work, but not the one I want to release, one of which I want to release well doesn't. If the application doesn't come up with a main window, the menus have troubles, or if it doesn't open an untitled document (same problem). Several others apps do work, but are very ugly. So, you propose that ALL apps look ugly under windows instead of at least try to blend in. The best way to get fixes for the windows theme is to put it into use. Possible solutions were discussed, but none implemented yet. Also ideas about directly with the app plist were put on the table. I'm not sure what you're referring to here. Right now it is too early, I propose to ship it together with system preferences, easy to enable, but not yet default. By what measure should we consider it ready? Riccardo GC -- 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: Next GNUstep release?
Just so we have a concrete idea of what's wrong, could you give me some examples of apps which have issues with the Windows theme? which I want to release well doesn't. If the application doesn't come up with a main window, the menus have troubles, or if it doesn't open an untitled document (same problem). Several others apps do work, but are very ugly. I believe this is a programming issue, not an issue for the framework to solve. GC -- 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: Next GNUstep release?
Top level objects in the nib are the responsibility of the controller. That is to say that if you load a nib from MyController then any and all top level objects in that nib should be released by MyController when it deallocates itself. On Sat, Mar 27, 2010 at 9:20 AM, Wolfgang Lux wolfgang@gmail.com wrote: Fred Kiefer wrote: Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, or so it seems from the outside and gui had to play catch up. Then I toyed around with the NIB loading and broke a few things. Now things are rather stable again and we should come back to our original plan. For gui this would be an intermediate release not the 1.0 release I am hoping to see later this year. What still needs to be done in gui is finishing the switch to #import, moving on to non fragile ivars will happen later. I first want to see the results base gets with its approach to that topic. Adam, could you once more take up the task of releasing GNUstep? We should give it another week or two so that people can complain about existing bugs that need to be fixed before the release. Well, just for a start: Rereading the Apple docs, I've noticed a (long-standing) incompatibility in the nib loading code. When one of the nib loading functions is called with an external name table and this dictionary contains the NS(Nib)TopLevelObjects key, GNUstep passes ownership of the top-level objects to the sender. However, this is not the case in Cocoa. Have a look at the Cocoa Resource Programming Guide and in particular the section Loading Nib Files into Your Program Programmatically (http://developer.apple.com/mac/library/documentation/cocoa/Conceptual/LoadingResources/CocoaNibs/CocoaNibs.html#//apple_ref/doc/uid/1051i-CH4-SW24). Try the example code from Listing 2-4 with your favorite nib/gorm file and you will observe a crash in GNUstep because the top-level objects are released once too often. While testing this, I've also noticed that NSNib.h does not define the string constants NSNibOwner and NSNibTopLevelObjects, which were introduced together with NSNib in 10.3. Please note that Apple uses the values @NSOwner and @NSTopLevelObjects for these constants for backward compatibility. This is documented in Apple's NSNib.h header file, but I couldn't find it in the online docs. I guess following Apple's approach would simplify the nib loading code in a few places. Wolfgang ___ 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
