Re: Next GNUstep release?
Hi Fred! Mhm, I already did all of that yesterday... But there is more to do. We now need to change all the places where we load NIB (or Gorm or XIB) files to free the top level objects. The code is a lot cleaner now, but as far as memory leaks are concerned we are almost back to square one. We now leak all the top level objects again :-( I will try to solve this later today, but wouldn't mind if anybody beats me on this before I come back from the cinema. Not sure if there is a misunderstanding here. With respect to the (usual?) case where applications don't explicitly ask for the top level objects, my patch did not change anything. The patch only affected the case where applications explicitly ask for the top level objects and in that case it ensures that those objects are not released prematurely (at least compared to Cocoa). So unless you mixed in some other changes, I don't see what you want to fix here. Wolfgang ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Hi I haven't kept up with the state of development/readiness of the windows theme, but I really don't agree with forcibly changing the default theme ... I know it makes me really irate on the odd occasion when Apple change default behaviors on OSX, and I have to look for the way to revert to previous behaviors. The theme is the user's choice ... so what should happen is that, on installation, the installer should ASK the user which theme they want to use, allowing them to select between available themes, but making the windows one the first selection (assuming here that for most apps it works well ... people can always change theme on a per-app basis anyway). If the user has already chosen a theme themselves (ie the default is already set in NSGlobalDomain) then the theme that they had previously chosen should be the first/default option when they are asked to choose a default theme ... so they can just hit the return key to continue using the last theme they selected. Although I generally agree with leaving the default theme as is on Unix, where we can theoretically strive for a complete environment, on Windows we always will be hosted, thus I consider it correct to have a more windows. friendly theme as the default on windows. I consider it an exception. Even when using a complete development environment you probably want that. Also, if you go as far as having several developer applications installed, you will be smart enough to be able to revert to the default theme if you wish. A default theme however must guarantee that any application can be compiled and work well without any further "porting efforts" to adapt it. This is not the case with the current WinUXTheme, although it works very well for some applications. I think a good proposal would be, if possible, to make the WinUXTheme as a user-selectable component in the NSIS installer, however selecting it should write automatically the global preferences so that it will be enabled. In this release I would make it by default unselected and maybe the next release will have it selected by default. I don't know however if the windows installer can be so smart to write the NSGlobalDomain when installing it? Riccardo ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Mhm, I already did all of that yesterday... But there is more to do. We now need to change all the places where we load NIB (or Gorm or XIB) files to free the top level objects. The code is a lot cleaner now, but as far as memory leaks are concerned we are almost back to square one. We now leak all the top level objects again :-( I will try to solve this later today, but wouldn't mind if anybody beats me on this before I come back from the cinema. Fred Am 29.03.2010 18:49, schrieb Gregory Casamento: > Wolfgang... > > The patch looks good. Please go ahead and apply it and make the > change in GSNibLoading.m as well, if you wish. > > Thanks, GC > > On Sun, Mar 28, 2010 at 4:45 PM, Wolfgang Lux wrote: >> Gregory Casamento wrote: >> >>> 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. >> >> Indeed. What I tried to point out (but maybe failed to do properly) is that >> GNUstep does not implement this policy when the controller explicitly asks >> for the top level objects using the NS(Nib)TopLevelObjects key. If one uses >> that key, GNUstep passes ownership of the top level objects exclusively to >> the array that is used to return the objects and when the controller >> releases the top level objects, the application will crash. In fact, it is >> even documented in the code that GSNibLoading and GSGormLoading are >> implemented that way. However, this is incompatible with both Apple's >> documentation and implementation. Attached below is a patch to fix >> GSGormLoading. A similar change will be necessary in GSNibLoading. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
Wolfgang... The patch looks good. Please go ahead and apply it and make the change in GSNibLoading.m as well, if you wish. Thanks, GC On Sun, Mar 28, 2010 at 4:45 PM, Wolfgang Lux wrote: > Gregory Casamento wrote: > >> 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. > > Indeed. What I tried to point out (but maybe failed to do properly) is that > GNUstep does not implement this policy when the controller explicitly asks > for the top level objects using the NS(Nib)TopLevelObjects key. If one uses > that key, GNUstep passes ownership of the top level objects exclusively to > the array that is used to return the objects and when the controller > releases the top level objects, the application will crash. In fact, it is > even documented in the code that GSNibLoading and GSGormLoading are > implemented that way. However, this is incompatible with both Apple's > documentation and implementation. Attached below is a patch to fix > GSGormLoading. A similar change will be necessary in GSNibLoading. > > Wolfgang > > > > > > -- 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?
Before FOSDEM we were planing a coordinated release of the GNUstep core components. In the meantime a lot has happened. Base was completely rewritten, Is gnustep-base really ready for a release so shortly after a large rewrite ? I assume we're talking of an unstable release ? ;-) Most of the 'rewriting' was really simplifying. In terms of line count, I wouldn't be surprised if there is less code in base now than in the last stable release - although there's a lot more in terms of features. In particular, Richard has done a lot of work on the test suite, and many of the 'rewritten' parts were fixing bugs that the test suite found. I've certainly found the svn base to be more reliable than nominally-stable base, and I think calling it an unstable release just means that no one uses it. I'm not trying to downplay how great the new software is. :-) I just wouldn't consider it well-tested yet. Testing takes time. We're mostly relying on crowd-testing, where we don't have much control over who is testing what. We just hope that if we wait enough, a good number of people will have tested it in various conditions and reported the problems they had. I think it's worth waiting a month or two after a big rewrite before we can claim the software is "stable". :-) See, I wouldn't use the new gnustep-base on mission critical production servers myself for a few months at least - I'm wondering if other people/users/companies would really want to ? ;-) By the way, I don't have a strong opinion on this - if other people feel there has been enough testing, you can make a stable release, I won't get offended or anything. :-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
On 29 Mar 2010, at 13:44, Nicola Pero wrote: > On 26 Mar 2010, at 20:55, 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, > > Is gnustep-base really ready for a release so shortly after a large rewrite ? > > I assume we're talking of an unstable release ? ;-) Most of the 'rewriting' was really simplifying. In terms of line count, I wouldn't be surprised if there is less code in base now than in the last stable release - although there's a lot more in terms of features. In particular, Richard has done a lot of work on the test suite, and many of the 'rewritten' parts were fixing bugs that the test suite found. I've certainly found the svn base to be more reliable than nominally-stable base, and I think calling it an unstable release just means that no one uses it. David -- Sent from my STANTEC-ZEBRA ___ 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 20:55, 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, Is gnustep-base really ready for a release so shortly after a large rewrite ? I assume we're talking of an unstable release ? ;-) Thanks ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
On 29 Mar 2010, at 07:37, Gregory Casamento wrote: > Hey guys... Matt and I just talked via IM and he reminded me of a > really important point. > > The functionality using proxies works fine on 32bit machines, but is > broken on 64 bit machines due to the fact that this bug: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700 > > has not seen release yet on most distros. There is a patched version > of this library on our ftp site. Actually it's the latest official release rather than a patched version. . > Should we turn off the NSImage proxy feature if it's on a 64bit system > for this release or, possibly, try to detect the version of libffi? That's a good idea ... we could perform the check for 64bit systems only, and insist on a working version ... after all broken ffi prevents a whole lot of things from working properly, producing obscure bugs anywhere that invocations are used ( NSUndoManager, NSConnection, NSTimer etc). ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Next GNUstep release?
On Sun, Mar 28, 2010 at 11:37 PM, Gregory Casamento wrote: > Hey guys... Matt and I just talked via IM and he reminded me of a > really important point. > > The functionality using proxies works fine on 32bit machines, but is > broken on 64 bit machines due to the fact that this bug: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40700 > named colors have this exact same issue and they were (haven't looked in a while) able to change without resorting to using an NSProxy for the color, the idea was that NSView observes the change, sets itself as needing redisplay, and views which cache colors are responsible to recache it, or they will keep displaying the old color, or crash if they cached and failed to retain it, this in my opinion works adequately. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
