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: 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: 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 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
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: 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
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
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
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
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
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: 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
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: 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
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
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.so.9
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
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
