Re: Coding style question
On Apr 14, 2008, at 9:56 AM, Markus Hitter wrote: Well, I'm still stunning why people prefer variable types of undefined size[1] (int, NSInteger, etc.) over those with defined size (int16, int32, int64, etc.). To my understanding of coding, one should always care about the size of variables, ruling out types of undefined size. Additionally, ideal code compiles and works on a 16 bit platform just as good as on a 128 bit platform, without conditional code or similar clutches. Generally, I think one should care about the minimum guaranteed range of variables, not the exact size. The exact size should only be important if one needs to rely on the overflow or modulo properties of the type, or perform I/O using a machine-independent network packet or file format. Using exact-sized types in cases where it is not necessary is over-specification, and may produce suboptimal code in some situations. At least as of C99, C specifies minimum ranges to be supported by the built-in types (see 5.2.4.2 Numerical Limits). I'm not sure if this was true prior to C99. -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
On Mar 30, 2008, at 5:31 PM, David Ayers wrote: Tim McIntosh schrieb: GNUstep seems to do a lot of mucking with the runtime structures that are no longer visible with Obj-C 2.0, so I think the changes I made were just barely scratching the surface in view of what is actually needed. Not being familiar enough with the GNUstep code base, I have to wonder if all of the direct use of the runtime APIs is really needed; I can see where it would be necessary on occasion within -base, but I was surprised by the number of times I saw it being used in higher-level frameworks. Indeed we heavily rely on that mucking in GDL2. But let me state this clearly... we are not mucking in the runtime for performance reasons... we are just trying to get WO45 compatibility. So if anyone has better ideas on how we can solve these issues with the public API of Foundation, I'm up for it! Thanks for the info and clarification. I didn't mean to pick on GDL2 here; I had just gotten the impression from experimenting with various things that the runtime API is used in a number of places outside of -base, and sometimes it was not clear why. I think part of this impression may have come from GSObjCRuntime.h getting pulled in by GSCategories.h in cases where it is not necessarily needed. This is why I was attempting to eliminate that #include. In any case, it looked to me like there may be a lot of work to do wrt supporting the GSObjCRuntime.h interface on the Apple's Obj-C 2.0 runtime (which is probably really only needed to support 64-bit; I can't see them removing the old APIs in the 32-bit version any time soon). Regards, Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: PATCH: suppress deprecation warnings on OS X Leopard
On Mar 30, 2008, at 9:27 AM, Nicola Pero wrote: The right fix still seems to be to update the Apple runtime code in gnustep-base to work with the new runtime if available, but in the meanwhile if we add the -Wno-deprecated flag, we should probably add it inside gnustep-base so that when support for the new runtime is available, we can remove it in sync. :-) It's been a few months, so I'm starting to forget everything, but IIRC, I did a small bit of work in this area when creating the GNUstepWeb packages for Mac OS X: http://hoth.radiofreeomaha.net:3000/~tmcintos/GNUstepWeb/ I believe I was also trying to reorganize some code to eliminate the need to include GSObjCRuntime.h in GSCategories.h and minimize the inclusion of GSObjCRuntime.h in general outside of -base. I was planning to go back and sort all of this out when I found some time-- reviewing everything, eliminating unnecessary changes, and breaking the remaining changes down into smaller patches that I could submit for consideration--but I haven't gotten around to that yet. GNUstep seems to do a lot of mucking with the runtime structures that are no longer visible with Obj-C 2.0, so I think the changes I made were just barely scratching the surface in view of what is actually needed. Not being familiar enough with the GNUstep code base, I have to wonder if all of the direct use of the runtime APIs is really needed; I can see where it would be necessary on occasion within - base, but I was surprised by the number of times I saw it being used in higher-level frameworks. -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: EOFault / NSAutoreleasePool
On Mar 13, 2008, at 12:03 PM, David Ayers wrote: Fred Kiefer schrieb: I only follow this discussion with out any deeper knowledge of the subject, so my suggestion may be utter nonsense. But to me it seems that NSAutoreleasePool does the right thing. It seems wrong to me to return a different selector from +instanceMethodForSelector: than from -methodForSelector:. If one would call: [[aFaultedObject class] instanceMethodForSelector:@selector(release)]; one would actually get the implementation of the unfaulted object. Yet if one would call that method directly on the faulted object, you'd get undefined behavior (ie most likely some kind of memory corruption if ivars are being accessed before some other method happens to fire the fault). But what NSAutoreleasePool was doing is: [GSObjCClass(aFaultedObject) instanceMethodForSelector:@selector(release)]; When this optimization was introduced I had to add the implementation to EOFault even though it shouldn't be needed. But since most other code never saw the EOFault class (as they call -class instead of GSObjCClass()), didn't use +instanceMethodForSelecotor: but called methods which would trigger forwardInvocation: (just like methodForSelector: does) that didn't much matter. Seems to me like this deserves a comment in -emptyPool, so it doesn't get broken inadvertently (again). One thing I've noticed while looking at GNUstep is some strange ways of doing things, like this, where it is not immediately evident why the normal pattern/idiom is not being used. It would be nice if all such things were clearly commented, so that it would be easier to know that the oddity was intentional rather than accidental. For instance in GSWeb I see occurrences of the following, which I had convinced myself is wrong: +(void)dealloc { ... [[self superclass]dealloc]; // should be [super dealloc] } -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: fyi - Mac OS native GDL2 / GSWeb Installer package
On Mar 11, 2008, at 3:11 PM, David Ayers wrote: David Ayers schrieb: Tim McIntosh schrieb: For example: [EMAIL PROTECTED]@count With Cocoa's -[NSArray valueForKeyPath:] behavior, this would invoke [object valueForKeyPath: @"[EMAIL PROTECTED]"] on each object in the display group, then return the sum of the counts. Actually, since Cocoa currently supports the aggregate keys, then maybe we need to move some of GDL2 KVC to -base... and then also -base's KVC would need more context with valueForKeyPath: on NSArray http://developer.apple.com/documentation/Cocoa/Reference/Foundation/Protocols/NSKeyValueCoding_Protocol/Reference/Reference.html [http://tinyurl.com/2cq4rg] I should've read this before responding to the previous message. ;) Yes, Cocoa supports the aggregate keys, though it's approach is apparently not extensible like the EOF design. Would it make sense to treat this as a GNUstep extension and implement it in the -base Additions? That way you would still override the Cocoa implementation on Mac OS and maintain the ability to extend the set of aggregate keys. -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: fyi - Mac OS native GDL2 / GSWeb Installer package
On Mar 11, 2008, at 2:02 PM, David Ayers wrote: Hello Tim. just a quick status report... Tim McIntosh schrieb: I think I was being too vague with regard to KVC. I wasn't referring to the deprecated KVC methods issue that has been discussed on the list recently, but something much more trivial. All I was talking about was the difference in behavior of -[NSDictionary valueForKey:] and -[NSDictionary storedValueForKey:] with respect to "special keys" (GDL2's @"allKeys" vs. Cocoa's @"@allKeys"), and the different handling of NSArray aggregate functions when there is a key path following the aggregating operator instead of a simple key. For example: [EMAIL PROTECTED]@count With Cocoa's -[NSArray valueForKeyPath:] behavior, this would invoke [object valueForKeyPath: @"[EMAIL PROTECTED]"] on each object in the display group, then return the sum of the counts. This definitely doesn't work with WO45, but I think it is a natural extension of its concepts. So I'm inclined to attempt to support it. The funny thing is, that I think we already could do this if NSObject's valueForKeyPath: would invoke valueForKeyPath: on the result of the valueForKey: of the first component with the remaining key path instead of calling valueForKey: with each component. Seems that way to me, but it sounds like -base is just following the Apple documentation, which says: "The default implementation gets the destination object for each relationship using valueForKey: and returns the result of a valueForKey: message to the final object." Yet this is currently just a theory and I suppose you were having issues on Cocoa's Foundation? From the above, it sounds like Cocoa's NSObject works the same as - base, but I didn't test it. Note: On Cocoa, I think it worked to just eliminate -valueForKeyPath: entirely from EOKeyValueCoding.m for this specific example, since Cocoa's NSArray implements a fixed set of operators, which includes the @sum and @count operators (see http://developer.apple.com/documentation/Cocoa/Conceptual/KeyValueCoding/Concepts/ArrayOperators.html) . However, since Cocoa does not implement the generalized/extensible behavior as found in EOF, I figured it would be better to stick with the implementation in EOKeyValueCoding if it could be made to provide a superset of what Cocoa supports. With GDL2's behavior, this would attempt to invoke [[object valueForKey: @"itemsArray"] decimalValue] on each object in the display group, sum the results, and then invoke [result valueForKey: @"@count"] on the sum--none of which would actually work as intended in this case. Actually I'm not sure I get this far yet with -base. But it's something I think we could handle. I'm not sure how far it was actually making it. I thought I was crashing on the -decimalValue message being sent to an array, but it's been too long since I actually debugged it to remember for sure. I think this deserves a feature request bug report. Maybe you could open one (assign it to gdl2 and me if that's possible). Possibly attach you patch also. https://savannah.gnu.org/bugs/index.php?22565 (Didn't see where I could assign you but I added you for e-mail notifications.) -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: fyi - Mac OS native GDL2 / GSWeb Installer package
Hi David, On Mar 6, 2008, at 7:54 AM, David Ayers wrote: Tim McIntosh schrieb: I have made a number of minor changes that I eventually intend to either undo or get accepted into the mainline. One difference in this version that may never make it into the mainline is the use of Cocoa-style (native) KVC (as opposed to WO-4.5 style), which I wanted for use with the WO5 app that I'm porting. It depends on how well we can emulate compatibility. Currently GSWeb/GDL2 is used for Projects that are currently still deployed as GNUstep based and WO45 based applications. So it's very important not to break WO45 compatibility. Yet if we can emulate it in a similar way as -base is currently trying, then I'd take the patches as long as they don't show issues. Sounds good. Do you really need to change the internal KVC? Maybe we just need to implement a few more legacy methods in EOKeyValueCoding.m to get it work on OS X. (And avoid some warnings from -base while we are at it.) I think I was being too vague with regard to KVC. I wasn't referring to the deprecated KVC methods issue that has been discussed on the list recently, but something much more trivial. All I was talking about was the difference in behavior of -[NSDictionary valueForKey:] and -[NSDictionary storedValueForKey:] with respect to "special keys" (GDL2's @"allKeys" vs. Cocoa's @"@allKeys"), and the different handling of NSArray aggregate functions when there is a key path following the aggregating operator instead of a simple key. For example: [EMAIL PROTECTED]@count With Cocoa's -[NSArray valueForKeyPath:] behavior, this would invoke [object valueForKeyPath: @"[EMAIL PROTECTED]"] on each object in the display group, then return the sum of the counts. With GDL2's behavior, this would attempt to invoke [[object valueForKey: @"itemsArray"] decimalValue] on each object in the display group, sum the results, and then invoke [result valueForKey: @"@count"] on the sum--none of which would actually work as intended in this case. My KVC changes are really pretty simple/naive (see attached patch). I was assuming this was an EOF vs. Cocoa behavior difference, but I'm not really sure about that. The old EOF documentation that I looked at didn't seem to be clear on what the behavior should be in this case, and I didn't have a setup where I could test EOF to see what it does, compared to GDL2. I don't have a high degree of confidence that I'm doing "the right thing" here, but I was trying to get a specific application working without changing any of its logic, and this seemed to do the trick. Thanks for your help, Tim EOKeyValueCoding.m.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GDL2 EOFault.m patch to fix -[EOFault forward::] on MacOS 10.4
On Mar 6, 2008, at 7:39 AM, David Ayers wrote: Is this patch too evil, or can we do something like this? Hehe... actually, it's not evil enough. ;-) I've committed a patch that should replace the runtime implementation pointer of EOFault's forward:: method with the one of NSObject. This should also save us a level of indirection at the price of not being able to set a breakpoint in gdb for EOFault'S forward::. For gnu-gnu-gnu (i.e. the GNU runtime) forward:: is actually not called anymore so I can't really test it. Could you please let me know if this works for you? Thanks! It works with the new patch below, i.e., check for NULL. I forgot to mention that it appears that forward:: is neither called nor implemented by NSObject under 10.5. It is implemented and called under 10.4. It allows -[EOFault forward::] to work on MacOS 10.4, gets rid of some code duplicated from NSObject.m, and allows the following unimplemented methods to be deleted from GSCategories.h and GSCompatibility.m in base: // Used only in EOFault.m, -[EOFault forward::], for Object compatibility @interface NSInvocation(GSCompatibility) - (retval_t) returnFrame:(arglist_t)args; - (id) initWithArgframe:(arglist_t)args selector:(SEL)selector; @end Indeed, if this works (and if that was really the last place these methods were used) then I'm fine with having this removed from -base. The comment shown above is from the actual code in SVN, though I don't know if it is true. I deleted these methods in my copy and have not noticed any problems, but that's not saying much. Thanks again, Tim EOFault.m.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
fyi - Mac OS native GDL2 / GSWeb Installer package
Hi All, I mentioned this last week over on the GSW Hackers list, but I'll repeat it here in case anyone is interested who doesn't subscribe to that list (I've also made some progress since my original post) - I've been working on a Mac OS native port of the GSWeb and GDL2 frameworks, for use with Xcode and the Cocoa frameworks outside of a full GNUstep environment. I have put together Installer packages for Mac OS 10.4 and 10.5, which can be found here: http://hoth.radiofreeomaha.net:3000/~tmcintos/GNUstepWeb/ I have made a number of minor changes that I eventually intend to either undo or get accepted into the mainline. One difference in this version that may never make it into the mainline is the use of Cocoa- style (native) KVC (as opposed to WO-4.5 style), which I wanted for use with the WO5 app that I'm porting. You are welcome to try it out if you're interested. Please keep in mind that this is unsupported work-in-progress. The build is Universal but I've only tested on PowerPC (no Intel machines here). Your mileage may vary. Thanks, -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GDL2 EOFault.m patch to fix -[EOFault forward::] on MacOS 10.4
Hi All,Is this patch too evil, or can we do something like this?It allows -[EOFault forward::] to work on MacOS 10.4, gets rid of some code duplicated from NSObject.m, and allows the following unimplemented methods to be deleted from GSCategories.h and GSCompatibility.m in base: // Used only in EOFault.m, -[EOFault forward::], for Object compatibility@interface NSInvocation(GSCompatibility)- (retval_t) returnFrame:(arglist_t)args;- (id) initWithArgframe:(arglist_t)args selector:(SEL)selector;@end-Tim EOFault.m.diff Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep-make and C++ projects...
On Mar 3, 2008, at 5:30 PM, Nicola Pero wrote: PS: The variables used to specify C++ and ObjC++ flags in gnustep- make are currently called CCFLAGS and OBJCCFLAGS (eg, ADDITIONAL_CCFLAGS, etc), not CXXFLAGS and OBJCXXFLAGS. Not sure why. If CXXFLAGS and OBJCXXFLAGS are more "natural" to C++ developers, we could set up a new terminology I guess; it would also be nice to be consistent with the new CXX variable used for the C++ compiler (I couldn't use CC there since it's already in use for the C/ObjC compiler). ;-) Oh, yeah, I was just talking about vanilla gmake--those are the variables used by its built-in rules (see gmake -p). I was not too familiar with what gnustep-make actually uses. I guess it doesn't matter, as long as you don't rely on the built-in rules. Sorry for the confusion, and thanks for clarifying this. -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstepBase: Unicode.m: NSProprietaryStringEncoding
On Mar 2, 2008, at 1:30 PM, Richard Frith-Macdonald wrote: On 2 Mar 2008, at 19:20, Tim McIntosh wrote: Should the #if around NSProprietaryStringEncoding (around line 210) be: #if OS_API_VERSION(GS_API_NONE,MAC_OS_X_VERSION_10_4) instead of: #if defined(GNUSTEP) I don't think so ... In MacOS-X NSProprietaryStringEncoding disappears after version 10.4, but in GNUstep it doesn't, and we don't want to disable the code on GNUstep systems. I guess we don't want to disable it when built on pre-10.5 macOS-X either, so perhaps it should be this ... #if defined(GNUSTEP) || OS_API_VERSION(GS_API_NONE,MAC_OS_X_VERSION_10_4) Yeah, I think that makes sense. Thanks, -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GNUstepBase: Unicode.m: NSProprietaryStringEncoding
Should the #if around NSProprietaryStringEncoding (around line 210) be: #if OS_API_VERSION(GS_API_NONE,MAC_OS_X_VERSION_10_4) instead of: #if defined(GNUSTEP) ? This is what I had in my private copy. Thanks, Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep-make and C++ projects...
On Mar 1, 2008, at 7:19 AM, Helge Hess wrote: On 01.03.2008, at 12:16, Nicola Pero wrote: make CC=g++ Hm, is there a special CC variable for CPP files? I think I wondered about that. There is CXX and CXXFLAGS. It would be nice if gnustep-make was to automatically do all of this. Not that sure how to decide when to use C++ linking (is it when only CC_FILES are non-empty and all the other xxx_FILES are empty ?) and how to best automate it. Suggestions from C++ users are welcome. Wouldn't it be whenever CC_OBJS or OBJCC_OBJS is non-empty? -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: RFA: Reorganize GS extensions (was: RFC: en/decodeBase64 relocation)
On Dec 8, 2007, at 4:43 AM, David Ayers wrote: - find a solution for extensions like NSStringEncoding enum Note that NSStringEncoding is an unsigned int in Mac OS X and OPENSTEP, not an enum (int) as it is in GNUstep. I noticed this discrepancy when attempting to decode .gorm files under OS X. -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: RFC: en/decodeBase64 relocation
On Dec 6, 2007, at 9:54 AM, Richard Frith-Macdonald wrote: my current feeling is that the best approacch is to try to move towards as completely compatible as we can with the main part of the base library, and isolate the extensions etc in the Additions subproject. Yes, yes, a thousand times yes. ;) The reasoning behind this is that our best bet for encouraging Apple developers to adopt GNUstep is by having them see good apps (such as GNUMail) which work in both worlds, and the best way to encourage ourselves to produce stuff that works on MacOS is to make sure that everything (from the includes we need to use to the undocumented behavior of individual methods) is as consistent between the two as possible. Amen. It would certainly be a great help to people like me, who occasionally get the silly idea to waste their entire weekend trying to create Xcode projects to build GNUstep apps & non-core frameworks on top of Apple's Foundation/AppKit without GS Make (okay maybe I'm the only one stupid enough to attempt this ;). One thing that recently bit me is that the OPENSTEP/MacOSX version numbers used in GSVersionMacros.h are incompatible/different than the same definitions on Mac OS X (e.g., MAC_OS_X_VERSION_10_2=100200 vs. 1020 in Mac OS); when compiling GNUstep stuff under Xcode, I end up picking up the Apple definition of MAC_OS_X_VERSION_MAX_ALLOWED, for example, which was causing the OS_API_VERSION(ADD,REM) macro to produce unexpected results. Modifying GSVersionMacros.h to use compatible version numbers solved the problem. Another thing I noticed is that it looks like GNUstep is going to have big problems if you ever want to jump to ObjC 2.0, at least on top of the Apple runtime. Deprecated methods in the Apple runtime seem to be used in lots of places. But main issue is: a) should we (continue to) add categories to standard classes b) should we try to limit all future extensions to custom classes I'm undecided leaning towards a) (at least until we have the first collision with OS X). I'm fairly happy with categories (though the possibility of a collision with MacOS-X methods of the same name does worry me a bit) as well as new custom classes, but I'd like to see them in separate header files so we have to explicitly include them and be more aware that we are using extensions. In theory, if we do that, then the only thing we would need to do to port a program to MacOS-X is to link it with the Additions library ... a single change to the makefile. I would also encourage people developing GNUstep applications to avoid using instance variables and private methods of (GNUstep) Foundation/ AppKit classes in application programs (why weren't the GS-specific instance variables declared @private, in the first place?), and instead add functionality to Additions, or find a portable way to do whatever needs to be done. This seems to be a common practice in the GS applications I've seen, and it has thwarted virtually every attempt I've made over the last 10 years to port nontrivial GNUstep apps to Mac OS X. That said, keep up the good work. -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Application crashes when embedding GNU Smalltalk lib - Help?
fyi - At the moment I seem to be successfully avoiding the problem by statically linking libgst (and libexecinfo) into my framework, as follows: LIBRARIES_DEPEND_UPON = -Wl,-Bsymbolic,-Bstatic,-lgst,-lexecinfo,- Bdynamic -lreadline -lm This is probably what I want to do anyway, since I'd like to encapsulate libgst in the framework to avoid the need to install it separately. -Tim On May 1, 2007, at 10:27 PM, Tim McIntosh wrote: Nicola, Good call! Apparently libgst includes libsnprintfv, which provides another version of register_printf_function (incompatible, of course -- it returns a pointer upon success). I'll have to think about how to best work around this. This brings up another question, though: is it really safe/ advisable to raise an exception in NSString +initialize? Is there a better way to handle this error condition? I've never seen the exception actually get printed; the app always crashes with SIGSEGV. In the original application where I first encountered this, I couldn't even get a usable stack trace--it looked like a stack overflow was occurring due to recursion or something. Thanks! -Tim On May 1, 2007, at 10:07 AM, Nicola Pero wrote: from the stacktrace that you provided, it seems that the problem is in NSString +initialize. In particular, you're getting the following exception: #ifdef HAVE_REGISTER_PRINTF_FUNCTION if (register_printf_function ('@', handle_printf_atsign, #if PRINTF_ATSIGN_VA_LIST 0)) #else arginfo_func)) #endif [NSException raise: NSGenericException format: @"register printf handling of %%@ failed"]; #endif /* HAVE_REGISTER_PRINTF_FUNCTION */ Maybe if you link GNU smalltalk, that interferes with register_printf_function() somehow ? Or anyway causes it to fail ___ 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: Application crashes when embedding GNU Smalltalk lib - Help?
Nicola, Good call! Apparently libgst includes libsnprintfv, which provides another version of register_printf_function (incompatible, of course -- it returns a pointer upon success). I'll have to think about how to best work around this. This brings up another question, though: is it really safe/advisable to raise an exception in NSString +initialize? Is there a better way to handle this error condition? I've never seen the exception actually get printed; the app always crashes with SIGSEGV. In the original application where I first encountered this, I couldn't even get a usable stack trace--it looked like a stack overflow was occurring due to recursion or something. Thanks! -Tim On May 1, 2007, at 10:07 AM, Nicola Pero wrote: from the stacktrace that you provided, it seems that the problem is in NSString +initialize. In particular, you're getting the following exception: #ifdef HAVE_REGISTER_PRINTF_FUNCTION if (register_printf_function ('@', handle_printf_atsign, #if PRINTF_ATSIGN_VA_LIST 0)) #else arginfo_func)) #endif [NSException raise: NSGenericException format: @"register printf handling of %%@ failed"]; #endif /* HAVE_REGISTER_PRINTF_FUNCTION */ Maybe if you link GNU smalltalk, that interferes with register_printf_function() somehow ? Or anyway causes it to fail ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Application crashes when embedding GNU Smalltalk lib - Help?
Does anyone happen to know why the mere presence of "-lgst" (GNU Smalltalk library) in the link would cause the attached app to crash? (see transcript below)Thanks!-TimTranscript:% uname -aFreeBSD kashyyyk.astro.net 6.2-RELEASE FreeBSD 6.2-RELEASE #0: Fri Jan 12 11:05:30 UTC 2007 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SMP i386### NOTE: As shown below, app runs when -lgst is suppressed; same results if the Test_GUI_LIBS line is simply removed from the Makefile: ###% gmake Test_GUI_LIBS=This is gnustep-make 2.0.0. Type ’make print-gnustep-make-help’ for help.Making all for app Test... Creating Test.app/ Compiling file main.m ... Linking app Test ... Creating Test.app/Resources... Creating Test.app/Resources/Info-gnustep.plist... Creating Test.app/Resources/Test.desktop...% openapp ./Test2007-04-29 19:33:45.080 Test[80416] Unable to read color file at "/Network/Users/tmcintos/Library/Colors/Emacs.clr" -- unknown format.^C% gmake cleanThis is gnustep-make 2.0.0. Type ’make print-gnustep-make-help’ for help.rm -rf ./*~ ./obj(cd .; \ rm -rf *.app)### NOTE: Here is the build with -lgst where the crash is observed: ###% gmakeThis is gnustep-make 2.0.0. Type ’make print-gnustep-make-help’ for help.Making all for app Test... Creating Test.app/ Compiling file main.m ... Linking app Test ... Creating Test.app/Resources... Creating Test.app/Resources/Info-gnustep.plist... Creating Test.app/Resources/Test.desktop...% openapp ./TestSegmentation fault% debugapp ./TestGNU gdb 6.1.1 [FreeBSD]Copyright 2004 Free Software Foundation, Inc.GDB is free software, covered by the GNU General Public License, and you arewelcome to change it and/or distribute copies of it under certain conditions.Type "show copying" to see the conditions.There is absolutely no warranty for GDB. Type "show warranty" for details.This GDB was configured as "i386-marcel-freebsd"...(gdb) runStarting program: /.amd_mnt/alderaan/Exports/Users/tmcintos/Development/SmallTalk/SmallStep/Test.subproj/Test.app/Testwarning: Unable to get location for thread creation breakpoint: generic error[New LWP 100098][New Thread 0x8054018 (LWP 100098)]Program received signal SIGSEGV, Segmentation fault.[Switching to Thread 0x8054018 (LWP 100098)]0x in ?? ()(gdb) bt#0 0x in ?? ()#1 0x2852fde2 in +[NSAutoreleasePool new] (self=0x28773a80, _cmd=0x28773b08) at NSAutoreleasePool.m:143#2 0x285300e4 in +[NSAutoreleasePool addObject:] (self=0x28773a80, _cmd=0x2879d208, anObj=0x80c9b60) at NSAutoreleasePool.m:247#3 0x285bbd30 in -[NSObject autorelease] (self=0x80c9b60, _cmd=0x287d6960) at NSObject.m:1790#4 0x28653a29 in +[NSString(GSCategories) stringWithFormat:arguments:] (self=0x287b2880, _cmd=0x28789f68, format=0x287b2ddc, argList=0xbfbfdc90 "x¬\t\b%") at GSCategories.m:1100#5 0x285828aa in +[NSException raise:format:arguments:] (self=0x28789d80, _cmd=0x28789f60, name=0x2878a07c, format=0x287b2ddc, argList=0xbfbfdc90 "x¬\t\b%") at NSException.m:751#6 0x28582854 in +[NSException raise:format:] (self=0x28789d80, _cmd=0x287b28e8, name=0x2878a07c, format=0x287b2ddc) at NSException.m:739#7 0x28602c39 in +[NSString initialize] (self=0x287b2880, _cmd=0x287c5408) at NSString.m:598#8 0x287edce7 in __objc_install_premature_dtable () from /usr/lib/libobjc.so.2#9 0x287ee3b0 in objc_msg_lookup () from /usr/lib/libobjc.so.2#10 0x285baca7 in +[NSObject initialize] (self=0x2879d140, _cmd=0x287c5408) at NSObject.m:1133#11 0x287edce7 in __objc_install_premature_dtable () from /usr/lib/libobjc.so.2#12 0x287edcf4 in __objc_install_premature_dtable () from /usr/lib/libobjc.so.2#13 0x287ee3b0 in objc_msg_lookup () from /usr/lib/libobjc.so.2#14 0x281a6ee1 in NSApplicationMain (argc=1, argv=0xbfbfdeb4) at Functions.m:53#15 0x0804868f in main (argc=1, argv=0xbfbfdeb4) at main.m:16(gdb) quitThe program is running. Exit anyway? (y or n) y% ldd Test.app/TestTest.app/Test: libgst.so.5 => /usr/local/lib/libgst.so.5 (0x2807a000) libgnustep-gui.so.0.13 => /System/Library/Libraries/libgnustep-gui.so.0.13 (0x28114000) libgnustep-base.so.1.15 => /System/Library/Libraries/libgnustep-base.so.1.15 (0x2847d000) libobjc.so.2 => /usr/lib/libobjc.so.2 (0x287e4000) libm.so.4 => /lib/libm.so.4 (0x287f8000) libpthread.so.2 => /lib/libpthread.so.2 (0x2880e000) libc.so.6 => /lib/libc.so.6 (0x28833000) libstdc++.so.5 => /usr/lib/libstdc++.so.5 (0x28918000) libreadline.so.6 => /lib/libreadline.so.6 (0x289e3000) libexecinfo.so.1 => /usr/local/lib/libexecinfo.so.1 (0x28a1) libaudiofile.so.0 => /usr/local/lib/libaudiofile.so.0 (0x28a1b000) libaspell.so.16 => /usr/local/lib/libaspell.so.16 (0x28a3f000) libungif.so.5 => /usr/local/lib/libungif.so.5 (0x28b0a000) libpng.so.5 => /usr/local/lib/libpng.so.5 (0x28b12000) libtiff.so.4 => /usr/local/lib/libtiff.so.4 (0x28b34000) libz.so.3 => /lib/libz.so.3 (0x28b82000) libjpeg.so.9 => /usr/local/lib/libjpeg.
mac FilesystemLayout is broken (patch)
Hi, Can someone fix the 'mac' file system layout? It is out of sync with the others. Attached are patches to core/make/FilesystemLayouts/mac and core/base/ Source/NSPathUtilities.m, which seem to fix the problems for me. The patch to NSPathUtilities.m is to fix NSSearchPathForDirectoriesInDomains(NSUserDirectory, NSAllDomainsMask, YES) so that it will just return ("/Users", "/ Network/Users") rather than ("/Users", "/Network/Users", ""). It attempts to change the handling of keys in the config file with empty values, so that they are treated as if they were not specified at all. Thanks! -Tim mac.patch Description: Binary data NSPathUtilities.m.patch Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSUserDirectory ... was Re: (no subject)
On Mar 6, 2007, at 5:27 AM, Richard Frith-Macdonald wrote: I agree ... it's not an idea I'd want to base my code on (I guess you can use NSHomeDirectoryForUser() in most cases). Presumably the idea is that you can iterate through the subdirectories of these paths to find all the 'normal' user directories. I've never needed to do that. I could also imagine using this to populate a list of default home directory locations in a user account creation program. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
GNUstep apps crash with SYSEGV on Debian/Alpha 3.1
Hi, On Debian/Alpha 3.1, most (all?) GNUstep apps seem to crash immediately on startup with SYSSEGV, as shown below. At the time of the crash, the menu, icons, and windows are shown on the display. This seems to be the same problem described here: http:// mirrors.p12n.org/bugs.debian.org/bts-spool-db/47/233747.log Does anyone know anything about this? Any hints on how to quickly isolate/ fix this problem would be appreciated. Thanks! -Tim [EMAIL PROTECTED]:~$ uname -a Linux alpha 2.4.27-3-generic #1 Tue Dec 5 18:39:08 UTC 2006 alpha GNU/ Linux Packages: ii gnustep3 The GNUstep Development Environment -- user ii gnustep-back 0.9.5-1The GNUstep GUI Backend ii gnustep-base-c 1.10.3-1 GNUstep Base library - common files ii gnustep-base-d 1.10.3-1 Documentation for the GNUstep Base Library ii gnustep-base-e 1.10.3-1 Examples using the GNUstep Base Library ii gnustep-core 3 The GNUstep Development Environment -- core ii gnustep-core-d 3 The GNUstep Development Environment -- core ii gnustep-core-d 3 The GNUstep Development Environment -- core ii gnustep-devel 3 The GNUstep Development Environment -- devel ii gnustep-exampl 1.0.0-1GNUstep Example Applications ii gnustep-gui-co 0.9.5-1GNUstep Gui Library - common files ii gnustep-gui-do 0.9.5-1Documentation for the GNUstep Gui Library ii gnustep-make 1.10.0-5 Basic GNUstep Scripts and Makefiles ii gnustep-make-d 1.10.0-5 Documentation for GNUstep-make ii gnustep-netcla 0.0.20040112-2 Objective-C framework for socket programming ii gnustep-ppd1.0.0-4GNUstep Postscript Printer Description ii libgnustep-bas 1.10.3-1 GNUstep Base library ii libgnustep-bas 1.10.3-1 GNUstep Base library - debug version ii libgnustep-bas 1.10.3-1 GNUstep Base header files and development li ii libgnustep-gui 0.9.5-1GNUstep Gui Library ii libgnustep-gui 0.9.5-1GNUstep Gui Library - debugging version ii libgnustep-gui 0.9.5-1GNUstep Gui header files and static librarie [EMAIL PROTECTED]:~$ debugapp Calculator.app GNU gdb 6.3-debian Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "alpha-linux"...(no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /usr/lib/GNUstep/System/Applications/Calculator.app/ Calculator (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread 16384 (LWP 1512)] (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) (no debugging symbols found) ---Type to continue, or q to quit--- (no debugging symbols found) (no debugging symbols found) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 1512)] 0x029e4ea8 in objc_msg_lookup () from /usr/lib/libobjc.so.1 (gdb) bt #0 0x029e4ea8 in objc_msg_lookup () from /usr/lib/libobjc.so.1 #1 0x026f073c in NSDecimalFromString () from /usr/lib/ GNUstep/System/Library/Libraries/libgnustep-base.so.1.10 #2 0x02000107abb8 in __builtin_avcall () from /usr/lib/ libavcall.so.0 Cannot access memory at address 0x20344180 (gdb) info reg v0 0x29df9e02199033608672 t0 0x0 0 t1 0x0 0 t2 0x12001a4c0 4831945920 t3 0x1200f6fa0 4832849824 t4 0x3a6e 14958 t5 0x2 2 t6 0x3 3 t7 0x7 7 s0 0x20344180 540295552 s1 0x2000
Re: [Gnustep-cvs] r22892 - in /libs/gui/trunk: ChangeLog Documentation/GuiUser/DefaultsSummary.gsdoc Source/GSDragView.m Source/NSApplication.m
Hi Fred, On May 11, 2006, at 5:41 PM, Fred Kiefer wrote: Quentin Mathé wrote: I think it could be better to phrase the key 'GSDontShowAppIcon' in an affirmative way, just 'GSShowAppIcon'. It seems to be the usual rule with boolean choice in UI and API. But then it was not the only reason, it is also easier to check that way, as the default, when the option is no specified at all, should be to show the icon. This also means that when you want to show the icon, you don't have to provide a setting, an option is only needed to switch it off. That's why I did stick with the way Saso decided to do it. How about something like one of the following? GSHideAppIcon GSDisableAppIcon GSInhibitAppIcon GSSuppressAppIcon -Tim ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: remote hosting
Hi Fred, Sorry for the confusion. The specific case that I want to work is as follows: I have a machine running GNUstep (call it 'localhost'). I log into this machine from another non-GNUstep machine (call it 'remotehost') using 'Xnest' (display ":1") to connect to the xdm on 'localhost'. Thus, DISPLAY is 'remotehost:1.0' and the GNUstep processes are running on 'localhost'. This "sort of" works without the patch. The initial processes that are launched _without_ the '-NSHost' argument will correctly display on 'remotehost:1.0', while printing the warning "NOTE: Only one display per host fully supported." However, the 'NSHost' default will be (incorrectly) set to 'remotehost' by the code I've proposed deleting. As I understand it, this default causes the programs to look for 'gdnc', 'gpbs', etc. on 'remotehost', instead of 'localhost', where they are actually running. The problem gets worse when one of those initial processes (e.g. GWorkspace) launches another GNUstep application via the NSWorkspace methods. Since the parent process has the 'NSHost' default set, the new process will be launched with the '-NSHost' argument (see NSWorkspace.m). When the -NSHost argument is specified, the code in the patched method (_initXContext) ignores the DISPLAY settings. Thus, the launched applications will use 'remotehost:0.0' for the display. This leads to some surprising results when 'remotehost:0.0' is a valid display. From looking at the code, I think you would also see a similar problem if you attempted to use display ":1" (or any nonzero display) on 'localhost', though I haven't tried this. I think it makes sense for the '-NSHost' argument to override the DISPLAY setting, as it does today. I think the problem is the assumption that the 'NSHost' default should be set according to DISPLAY if -NSHost was not explicitly specified. As I see it, the '- NSHost' argument says that I want to connect to a remote GNUstep session. If I don't specify -NSHost, I'm saying I want to run GNUstep on the local host and display according to the DISPLAY setting. I realize that this is slightly less convenient in the case where you want to use a remote GNUstep session on 'remotehost:0.0' and would like to rely on the DISPLAY setting, but I'd rather have more control over the display. Having to specify the -NSHost argument seems reasonable, especially considering that you had to do this under OPENSTEP and you'd have to do it anyway if you weren't using X11. Tim On Jan 30, 2006, at 4:30 AM, Fred Kiefer wrote: Hi Tim, I read through your mail and your patch, but still don't quite get the issue you have. It is a know problem that GNUstep will complain about multiple displays and it even may not work fully correctly in that case, but what is causing you problems? What value are you using for DISPLAY? ":0.3" or ":1.0" or "localhost:1.0"? And in what way does it harm your application that NSHost gets automatically set? What value does it get set to? I would expect that having NSHost set to something like "localhost" would result in the same behaviour as not having it set at all. If this is not the case, we need to look into that. I am not sure, if your solution, forcing people to set two environment variable to matching values, is a great idea. It most likely will result in additional problems. Fred ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: remote hosting
Hello, I tried to send this message last week, but there were problems with my list subscription so I think it ended up in a black hole somewhere. Has anyone ever addressed the issues raised in http://lists.gnu.org/ archive/html/gnustep-dev/2002-01/msg00013.html, regarding -NSHost support with X? I couldn't find any further discussion on this topic. Two issues arising from recent discussions on the mailing list - 1. X systems can have multiple 'displays' (each display consisting or a keyboard, a mouse, and one or more screens), but the NSHost mechanism presumes that a host is a workstation with a single user. Should we implement some extension to -NSHost to allow for this? 2. X systems can be dumb machines without GNUstep running, so would not run the pasteboard, notification centre, and workspace processes Should we implement some mechanism whereby some other GNUstep machine could run the required processes on behalf of the dumb X terminal? Ignoring, for now, the problem of supporting multiple GNUstep users on a single host, I'd like to have the ability to use a DISPLAY setting other than ":0.0" while using a local GNUstep session (gpbs, gdnc, etc.). This would allow me to run GNUstep on a local display other than ":0.0", or control a machine remotely via a dumb Xterminal. Today, this doesn't seem to be possible, as it is assumed that a GNUstep session is running on the remote host. To allow this to work, I propose deleting the code that automatically sets the "NSHost" default whenever -NSHost is not specified and DISPLAY is defined (see attachment). This would produce the behavior described by the table below. The only difference from today is in case (B). The proposed change would make it necessary to specify the -NSHost argument whenever you want to connect to a remote GNUstep session; it does NOT attempt to address the issue of being able to specify a display other than "remote:0.0" when using -NSHost. -NSHost specified? DISPLAY defined? Behavior A. NO NO Local GNUstep session, display on local:0.0 B. NO YES Local GNUstep session, display on $DISPLAY C. YES NO Remote GNUstep session, display on remote:0.0 D. YES YES Remote GNUstep session, display on remote:0.0 (DISPLAY ignored) This behavior seems reasonable to me, and supports my needs. However, I'm not really familiar with the GNUstep internals, so please set me straight if this is a bad idea. Otherwise, I'd be very happy if someone could implement this change in the main distribution. I could enter this as a bug report if that's the appropriate course of action for change requests. Thanks, Tim McIntosh XGServer.m.patch Description: Binary data ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev