Re: Allowing Applications to continue after exception...
On Wed, Feb 4, 2009 at 9:50 PM, David Ayers wrote: > Am Mittwoch, den 04.02.2009, 23:52 -0500 schrieb Gregory Casamento: >> The attached test program does not crash on Mac OS X when the button >> is pressed, but does crash on GNUstep. The button calls the "action:" >> method in Controller which immediately throws an exception. >> >> I believe this confirms that GNUstep's behavior is inconsistent with >> Cocoa. I can test on OpenStep, but I suspect that the behavior is >> the same there as it is on Cocoa. > > FWIW, IIRC this inconsistency was intentional an I believe for a very > good reason. I thought we had documented it at the time but I can't dig > it up easily right now. > > An uncaught exception indicates that the application is in an undefined > state. For certain type of applications (like viewers) this can be > ignored. For editor application this could mean that the document being > edited could be corrupted and saving it cause data corruption. > > This thread is the only reference I found in which we suggested some > type of "Developer-Mode" which indicates that "I know what I'm doing, > let me debug, will you?!". > > http://lists.gnu.org/archive/html/discuss-gnustep/2004-10/msg00092.html > > I still believe that handling generic handling of exceptions in the > runloop is a dangerously wrong and an implementation detail that we > shouldn't try to be compatible with. But others may disagree. I definitely agree with this, but wanted to toss out another point of view in the same vein in an editor application, say that there is an exception when working with a single document (i'm seeing something in DBModeler when closing certain documents which I haven't managed to fix yet unfortunately) so i'm getting an exception when an error occurs in a single document, but the entire application crashes, now i should probably add some exception handling somewhere (not exactly sure where, probably all over the place...) to my app but haven't figured out where yet, but until I do, an exception in a single document means that all open documents close, and could potentially lose changes in other unsaved documents which are open. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 5 Feb 2009, at 07:23, Gregory John Casamento wrote: Richard, "True. Such applications are fundamentally badly designed/buggy, but it generally doesn't win you any friends to say so." That could be true, but I don't believe, however, that GNUstep should fail where Cocoa recovers. I'm sure David's point was that, at the moment, GNUstep limits damage where Cocoa trashes things. It's not at all true to say that GNUstep fails and Cocoa recovers ... more true to say that cocoa hides bugs and often gets away with it. Anyway, we should implement the NSExceptionMask user default and the issue then becomes irrelevant as we can control which behavior we want for a particular application. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
Richard, "True. Such applications are fundamentally badly designed/buggy, but it generally doesn't win you any friends to say so." That could be true, but I don't believe, however, that GNUstep should fail where Cocoa recovers. The fact of the matter is that differences like this fundamentally impact portability between Cocoa/OpenStep and GNUstep. "In truth the best behavior depends on the circumstances ... probably it's more often good to keep running in a gui app, as there is a human being there to notice the problem, and it's generally best to abort in any other circumstances, to minimise the damage that might be caused." Agreed. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Richard Frith-Macdonald To: Gregory John Casamento Cc: David Ayers ; Gregory Casamento ; Adam Fedor ; Developer GNUstep Sent: Thursday, February 5, 2009 1:49:54 AM Subject: Re: Allowing Applications to continue after exception... On 5 Feb 2009, at 06:15, Gregory John Casamento wrote: > David, > > Simply because an exception is thrown and not caught does not necessarily > mean that the application is in an unknown state. That really depends on your use of the work 'unknown'. Obviously if I've planned it, or if I catch it under debug and examine the stack and data structures, then I know the state, but that's not the point. The point is that the generic code in our library doesn't know the state of the system and has no way of knowing what the best way to deal with the exception is. > Indeed some applications may have come to rely on this behavior and it makes > it very difficult to port applications which do this without refactoring. True. Such applications are fundamentally badly designed/buggy, but it generally doesn't win you any friends to say so. It's not as if > As far as being "dangerously wrong" I believe it's equally wrong (or, > perhaps, worse) to have the application blow up when an exception is easily > recoverable and isn't fatal. Yes ... but it's the application programmers responsibility to recover from a recoverable exception. If they didn't put in any code to recover from an exception then the enclosing code is supposed assume that it was an unrecoverable error, because it can't know whether the exception is truly recoverable or not. That's the whole nature of the exception handling paradigm. > The philosophy is that, if it is possible to continue... it should continue. > It is up to the app developer to catch the exception and take appropriate > action. If it's a fatal exception, it should be up to the developer of the > application to cause the app to terminate. That's the opposite of conventional logic for exception handling (in which it's the developer's responsibility to do error recovery, not their responsibility to abort). However, if it's up to the developer of the application to cause the app to terminate, then they should have caught the exception and terminated the app. In neither case should the exception have reached our code. In truth the best behavior depends on the circumstances ... probably it's more often good to keep running in a gui app, as there is a human being there to notice the problem, and it's generally best to abort in any other circumstances, to minimise the damage that might be caused. > We should NOT force the decision. We can't help it ... we have to implement some behavior. NEWS ... after saying all that, I actually searched for everything I could find about exception handling in MacOS-X (to see what they actually tell their developers to do), and there's new stuff there. It seems that they've actually implemented the sort of user default based control I suggested in my previous email: See http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Tasks/ControllingAppResponse.html#//apple_ref/doc/uid/2473-BBCHGJIJ It also sounds like they've added a whole framework for exception handling. Duplicating that might take some time, but the basic handling mask in the default system should be quite easy to do. Interestingly, it seems that for secondary threads they do normal exception handling and just terminate the thread. The catching and logging stuff is normally done only in the main thread. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 5 Feb 2009, at 06:15, Gregory John Casamento wrote: David, Simply because an exception is thrown and not caught does not necessarily mean that the application is in an unknown state. That really depends on your use of the work 'unknown'. Obviously if I've planned it, or if I catch it under debug and examine the stack and data structures, then I know the state, but that's not the point. The point is that the generic code in our library doesn't know the state of the system and has no way of knowing what the best way to deal with the exception is. Indeed some applications may have come to rely on this behavior and it makes it very difficult to port applications which do this without refactoring. True. Such applications are fundamentally badly designed/buggy, but it generally doesn't win you any friends to say so. It's not as if As far as being "dangerously wrong" I believe it's equally wrong (or, perhaps, worse) to have the application blow up when an exception is easily recoverable and isn't fatal. Yes ... but it's the application programmers responsibility to recover from a recoverable exception. If they didn't put in any code to recover from an exception then the enclosing code is supposed assume that it was an unrecoverable error, because it can't know whether the exception is truly recoverable or not. That's the whole nature of the exception handling paradigm. The philosophy is that, if it is possible to continue... it should continue. It is up to the app developer to catch the exception and take appropriate action. If it's a fatal exception, it should be up to the developer of the application to cause the app to terminate. That's the opposite of conventional logic for exception handling (in which it's the developer's responsibility to do error recovery, not their responsibility to abort). However, if it's up to the developer of the application to cause the app to terminate, then they should have caught the exception and terminated the app. In neither case should the exception have reached our code. In truth the best behavior depends on the circumstances ... probably it's more often good to keep running in a gui app, as there is a human being there to notice the problem, and it's generally best to abort in any other circumstances, to minimise the damage that might be caused. We should NOT force the decision. We can't help it ... we have to implement some behavior. NEWS ... after saying all that, I actually searched for everything I could find about exception handling in MacOS-X (to see what they actually tell their developers to do), and there's new stuff there. It seems that they've actually implemented the sort of user default based control I suggested in my previous email: See http://developer.apple.com/DOCUMENTATION/Cocoa/Conceptual/Exceptions/Tasks/ControllingAppResponse.html#/ /apple_ref/doc/uid/2473-BBCHGJIJ It also sounds like they've added a whole framework for exception handling. Duplicating that might take some time, but the basic handling mask in the default system should be quite easy to do. Interestingly, it seems that for secondary threads they do normal exception handling and just terminate the thread. The catching and logging stuff is normally done only in the main thread. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 5 Feb 2009, at 05:50, David Ayers wrote: http://lists.gnu.org/archive/html/discuss-gnustep/2004-10/ msg00092.html I still believe that handling generic handling of exceptions in the runloop is a dangerously wrong and an implementation detail that we shouldn't try to be compatible with. But others may disagree. Well I agree that it's obviously dangerously wrong ... but I'm not sure that means we shouldn't do it anyway. Pragmatically, it seems like the vast majority of exceptions do not indicate anything very harmful, so continuing is not a problem for those cases, so compatibility might generally make sense. What we could do is make the behavior selectable (with a user default for instance), and use it as a selling points that we can switch applications over to a 'secure' mode where they won't screw up like Apple ones might. One more thing to note ... it's not as simple as just looking at the case of catching exceptions in the application's event loop. GNUstep- base is already broken in this way in that it's Apple compatible in catching/logging exceptions inside timers and notification handlers (possibly other places too I guess). This has actually bitten me once ... where an error in a timer meant that we got a huge logfile generated, filling the disc and bringing an entire server down because the process kept running and our monitoring software therefore didn't alert us of the error. In this case, not being Apple compatible would have saved us half an hour of downtime, which is important when you are running 24x7 servers. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
David, Simply because an exception is thrown and not caught does not necessarily mean that the application is in an unknown state. Indeed some applications may have come to rely on this behavior and it makes it very difficult to port applications which do this without refactoring. As far as being "dangerously wrong" I believe it's equally wrong (or, perhaps, worse) to have the application blow up when an exception is easily recoverable and isn't fatal. The philosophy is that, if it is possible to continue... it should continue. It is up to the app developer to catch the exception and take appropriate action. If it's a fatal exception, it should be up to the developer of the application to cause the app to terminate. We should NOT force the decision. Later, GC Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: David Ayers To: Gregory Casamento Cc: Adam Fedor ; Developer GNUstep Sent: Thursday, February 5, 2009 12:50:15 AM Subject: Re: Allowing Applications to continue after exception... Am Mittwoch, den 04.02.2009, 23:52 -0500 schrieb Gregory Casamento: > The attached test program does not crash on Mac OS X when the button > is pressed, but does crash on GNUstep. The button calls the "action:" > method in Controller which immediately throws an exception. > > I believe this confirms that GNUstep's behavior is inconsistent with > Cocoa. I can test on OpenStep, but I suspect that the behavior is > the same there as it is on Cocoa. FWIW, IIRC this inconsistency was intentional an I believe for a very good reason. I thought we had documented it at the time but I can't dig it up easily right now. An uncaught exception indicates that the application is in an undefined state. For certain type of applications (like viewers) this can be ignored. For editor application this could mean that the document being edited could be corrupted and saving it cause data corruption. This thread is the only reference I found in which we suggested some type of "Developer-Mode" which indicates that "I know what I'm doing, let me debug, will you?!". http://lists.gnu.org/archive/html/discuss-gnustep/2004-10/msg00092.html I still believe that handling generic handling of exceptions in the runloop is a dangerously wrong and an implementation detail that we shouldn't try to be compatible with. But others may disagree. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
Am Mittwoch, den 04.02.2009, 23:52 -0500 schrieb Gregory Casamento: > The attached test program does not crash on Mac OS X when the button > is pressed, but does crash on GNUstep. The button calls the "action:" > method in Controller which immediately throws an exception. > > I believe this confirms that GNUstep's behavior is inconsistent with > Cocoa. I can test on OpenStep, but I suspect that the behavior is > the same there as it is on Cocoa. FWIW, IIRC this inconsistency was intentional an I believe for a very good reason. I thought we had documented it at the time but I can't dig it up easily right now. An uncaught exception indicates that the application is in an undefined state. For certain type of applications (like viewers) this can be ignored. For editor application this could mean that the document being edited could be corrupted and saving it cause data corruption. This thread is the only reference I found in which we suggested some type of "Developer-Mode" which indicates that "I know what I'm doing, let me debug, will you?!". http://lists.gnu.org/archive/html/discuss-gnustep/2004-10/msg00092.html I still believe that handling generic handling of exceptions in the runloop is a dangerously wrong and an implementation detail that we shouldn't try to be compatible with. But others may disagree. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 4 Feb 2009, at 20:23, Gregory Casamento wrote:
I definitely think we should implement something similar. It would
help a great deal with some porting efforts.
On Wed, Feb 4, 2009 at 3:03 PM, David Chisnall
wrote:
On 4 Feb 2009, at 18:53, Gregory Casamento wrote:
In some cases on Mac OS X I have observed that exceptions which are
not fatal on Mac sometimes ARE fatal on GNUstep. I believe we
should change the logic which deals with exceptions to add a
"continue" button and only show the panel when the application is
running in debug mode. This would allow the application to
continue when recovery is possible.
Does anyone have any thoughts on this?
The OS X behaviour appears to be for each runloop iteration to be
wrapped in a @try{} block with the exception being NSLog'd if it
occurs during the runloop. This is quite convenient for debugging,
since you can just read the log and find out where the exception
happened, without having to
Logging any exception in the application main runloop ought to be
pretty easy to implement.
Would we wnat to look at other bits of code running event loops, and
trap exceptions there too?
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On Feb 4, 2009, at 1:23 PM, Gregory Casamento wrote:
I definitely think we should implement something similar. It would
help a great deal with some porting efforts.
On Wed, Feb 4, 2009 at 3:03 PM, David Chisnall
wrote:
On 4 Feb 2009, at 18:53, Gregory Casamento wrote:
In some cases on Mac OS X I have observed that exceptions which are
not fatal on Mac sometimes ARE fatal on GNUstep. I believe we
should change the logic which deals with exceptions to add a
"continue" button and only show the panel when the application is
running in debug mode. This would allow the application to
continue when recovery is possible.
Does anyone have any thoughts on this?
The OS X behaviour appears to be for each runloop iteration to be
wrapped in a @try{} block with the exception being NSLog'd if it
occurs during the runloop. This is quite convenient for debugging,
since you can just read the log and find out where the exception
happened, without having to
David
Yes, I've found it useful for debugging, particularly when you've just
implemented a bunch of things. Just logging the exception allows you
to see how the app operates in general, even it the behavior is off.___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
I definitely think we should implement something similar. It would help a
great deal with some porting efforts.
On Wed, Feb 4, 2009 at 3:03 PM, David Chisnall wrote:
> On 4 Feb 2009, at 18:53, Gregory Casamento wrote:
>
> In some cases on Mac OS X I have observed that exceptions which are not
>> fatal on Mac sometimes ARE fatal on GNUstep. I believe we should change
>> the logic which deals with exceptions to add a "continue" button and only
>> show the panel when the application is running in debug mode. This would
>> allow the application to continue when recovery is possible.
>>
>> Does anyone have any thoughts on this?
>>
>
> The OS X behaviour appears to be for each runloop iteration to be wrapped
> in a @try{} block with the exception being NSLog'd if it occurs during the
> runloop. This is quite convenient for debugging, since you can just read
> the log and find out where the exception happened, without having to
>
> David
>
--
Gregory Casamento
Open Logic Corporation, Principal Consultant
## GNUstep Chief Maintainer
yahoo/skype: greg_casamento, aol: gjcasa
(240)274-9630 (Cell), (301)362-9640 (Home)
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 4 Feb 2009, at 18:53, Gregory Casamento wrote:
In some cases on Mac OS X I have observed that exceptions which are
not fatal on Mac sometimes ARE fatal on GNUstep. I believe we
should change the logic which deals with exceptions to add a
"continue" button and only show the panel when the application is
running in debug mode. This would allow the application to
continue when recovery is possible.
Does anyone have any thoughts on this?
The OS X behaviour appears to be for each runloop iteration to be
wrapped in a @try{} block with the exception being NSLog'd if it
occurs during the runloop. This is quite convenient for debugging,
since you can just read the log and find out where the exception
happened, without having to
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
This is what I was thinking... the reason I'm thinking about this is because I am working on porting a few apps and exception which show up in the log on Mac OS X cause GNUstep to die. GC On Wed, Feb 4, 2009 at 2:52 PM, Matt Rice wrote: > On Wed, Feb 4, 2009 at 11:14 AM, Richard Frith-Macdonald > wrote: > > > > On 4 Feb 2009, at 18:53, Gregory Casamento wrote: > > > >> In some cases on Mac OS X I have observed that exceptions which are not > >> fatal on Mac sometimes ARE fatal on GNUstep. I believe we should > change > >> the logic which deals with exceptions to add a "continue" button and > only > >> show the panel when the application is running in debug mode. This > would > >> allow the application to continue when recovery is possible. > >> > >> Does anyone have any thoughts on this? > > > > I think the panel is shown when there is an UNCAUGHT exception. > > If the exception has not been caught, there is nowhere to return to and > no > > way to continue ... so adding a continue button and returning from the > > uncaught exception handler would not allow the application to continue. > > > > If you want an exception to not be fatal, you have to write code to > handle > > it and continue. > > > > Sometimes you might think you can continue running, but know that the app > > probably won't be doing what the user expects. In this situation it > makes > > sense to display an alert panel explaining the nature of the problem, and > > allow the user to choose between continuing and cleanly terminating. > This > > however is a very different case from the panel shown when the uncaught > > exception handler is called. > > > > > > there might be an handler in the NSApplication -run method which > allows the runloop to continue iterating... > i seem to recall an old version of openstep doing something to this > effect with uncaught exceptions, didn't show a panel, or NSLog > anything, or abort unless of course i was using NSAssert, and it was > doing something with the c preprocessor to get rid of my NSAsserts, > which seems possible :) > -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On Wed, Feb 4, 2009 at 11:14 AM, Richard Frith-Macdonald wrote: > > On 4 Feb 2009, at 18:53, Gregory Casamento wrote: > >> In some cases on Mac OS X I have observed that exceptions which are not >> fatal on Mac sometimes ARE fatal on GNUstep. I believe we should change >> the logic which deals with exceptions to add a "continue" button and only >> show the panel when the application is running in debug mode. This would >> allow the application to continue when recovery is possible. >> >> Does anyone have any thoughts on this? > > I think the panel is shown when there is an UNCAUGHT exception. > If the exception has not been caught, there is nowhere to return to and no > way to continue ... so adding a continue button and returning from the > uncaught exception handler would not allow the application to continue. > > If you want an exception to not be fatal, you have to write code to handle > it and continue. > > Sometimes you might think you can continue running, but know that the app > probably won't be doing what the user expects. In this situation it makes > sense to display an alert panel explaining the nature of the problem, and > allow the user to choose between continuing and cleanly terminating. This > however is a very different case from the panel shown when the uncaught > exception handler is called. > > there might be an handler in the NSApplication -run method which allows the runloop to continue iterating... i seem to recall an old version of openstep doing something to this effect with uncaught exceptions, didn't show a panel, or NSLog anything, or abort unless of course i was using NSAssert, and it was doing something with the c preprocessor to get rid of my NSAsserts, which seems possible :) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Allowing Applications to continue after exception...
On 4 Feb 2009, at 18:53, Gregory Casamento wrote: In some cases on Mac OS X I have observed that exceptions which are not fatal on Mac sometimes ARE fatal on GNUstep. I believe we should change the logic which deals with exceptions to add a "continue" button and only show the panel when the application is running in debug mode. This would allow the application to continue when recovery is possible. Does anyone have any thoughts on this? I think the panel is shown when there is an UNCAUGHT exception. If the exception has not been caught, there is nowhere to return to and no way to continue ... so adding a continue button and returning from the uncaught exception handler would not allow the application to continue. If you want an exception to not be fatal, you have to write code to handle it and continue. Sometimes you might think you can continue running, but know that the app probably won't be doing what the user expects. In this situation it makes sense to display an alert panel explaining the nature of the problem, and allow the user to choose between continuing and cleanly terminating. This however is a very different case from the panel shown when the uncaught exception handler is called. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Allowing Applications to continue after exception...
In some cases on Mac OS X I have observed that exceptions which are not fatal on Mac sometimes ARE fatal on GNUstep. I believe we should change the logic which deals with exceptions to add a "continue" button and only show the panel when the application is running in debug mode. This would allow the application to continue when recovery is possible. Does anyone have any thoughts on this? Later, GC -- Gregory Casamento Open Logic Corporation, Principal Consultant ## GNUstep Chief Maintainer yahoo/skype: greg_casamento, aol: gjcasa (240)274-9630 (Cell), (301)362-9640 (Home) ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Off to FOSDEM
Hi, On Wed, Feb 4, 2009 at 5:23 PM, Richard Frith-Macdonald wrote: > I'll be leaving for FOSDEM tomorrow morning and won't be home again until > Monday evening. > My availability on email over that period will be very patchy. > Hope to see a few of you there. Well on my side, it looks I may only be able to come the saturday intead of the whole weekend... Would it be possible to swap the Pragmatic Smalltalk presentation from sunday morning to saturday ? Or is there somebody willing to give the talk ? (slides furnished !) Cheers, -- Nicolas Roard "I love deadlines. I like the whooshing sound they make as they fly by." -- Douglas Adams ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Off to FOSDEM
Have a safe trip. Gregory Casamento -- Principal Consultant - OLC, Inc # GNUstep Chief Maintainer From: Richard Frith-Macdonald To: Developer GNUstep Sent: Wednesday, February 4, 2009 12:23:30 PM Subject: Off to FOSDEM I'll be leaving for FOSDEM tomorrow morning and won't be home again until Monday evening. My availability on email over that period will be very patchy. Hope to see a few of you there. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Off to FOSDEM
I'll be leaving for FOSDEM tomorrow morning and won't be home again until Monday evening. My availability on email over that period will be very patchy. Hope to see a few of you there. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
