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
Apache2 adaptor updated
Hi folks, I updated the Apache2 adaptor. It should be a lot faster now :) Please test it. Dave ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: RFC: en/decodeBase64 relocation
On 2007-12-06 15:12:30 + David Ayers <[EMAIL PROTECTED]> wrote: Richard Frith-Macdonald schrieb: On 2007-12-02 21:32:17 + David Ayers <[EMAIL PROTECTED]> wrote: Hello everyone, Even though base64 encoding is primarily used with MIME processing, its usage does spring up here in related and unrelated scenarios. It also seems more natural as an NSData category to me. I'm wondering whether this patch: moving the implementation of GSMime en/decodeBase64: to an NSData en/decodeBase64 category would be considered too much of a name pollution issue wrt NSData. I've had this patch in my tree for some time now (had to clean it up a bit and check for new usage of the current method so I cleanup some compiler warnings while I was at it to make sure I don't miss one). I agree that it seems natural as an NSData category, but I also think we need to avoid pollution of the basic headers/classes, so I don't think the patch is a good idea. mhm... IMO a more 'correct' patch would be to: 1. Put the implementation in Source/Additions/GSCategories.m (and the declaration in Headers/Additions/GNUstep/GSCategories.h) 2. Mark the methods in GSMime.h as deprecated and to be removed in version 1.17.0 3. Change GSMime.m and all files currently using the methods to use the NSData methods and include GSCategories.h I'm a bit confused... or I should have explained it better but I thought the patch did these things... well almost. Probably I failed to follow what was going on well enough. I've also added the declarations to the NSData.h header because -base avoids including GSCategories.h declarations when building itself and relies on the extensions being declared in GNUstep's standard headers. I it was once explained to me that this was done to avoid having folks who merely target GNUstep from having to include the special headers. I guess I'd forgotten this. But maybe we should reconsider this approach and change remove the: /* The following ifndef prevents the categories declared in this file being * seen in GNUstep code. This is necessary because those category * declarations are also present in the header files for the corresponding * classes in GNUstep. The separate category declarations in this file * are only needed for software using the GNUstep Additions library * without the main GNUstep base library. */ #ifndef GNUSTEP in GSCategories.h Well, I think so. I don;t know who wrote that (it could well have been me), but 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. 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. But maybe you just mean that the method of deprecation isn't optimal. What I did is that I simply removed the old method declaration from the GSMime.h header but left the implementation which produces a warning when invoked before forwarding it to the NSData category. The warning also doesn't specify a specific version of when the implementation would be removed. Yes, I was meaning that the use of the GS_API_VERSION macro in the header would produce the appropriate information in the auto-generated documentation (in addition to the runtime warning). 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. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: RFC: en/decodeBase64 relocation
Richard Frith-Macdonald schrieb: > On 2007-12-02 21:32:17 + David Ayers <[EMAIL PROTECTED]> wrote: > >> Hello everyone, >> >> Even though base64 encoding is primarily used with MIME processing, its >> usage does spring up here in related and unrelated scenarios. It also >> seems more natural as an NSData category to me. >> >> I'm wondering whether this patch: >> >> moving the implementation of GSMime en/decodeBase64: to an NSData >> en/decodeBase64 category >> >> would be considered too much of a name pollution issue wrt NSData. >> >> I've had this patch in my tree for some time now (had to clean it up a >> bit and check for new usage of the current method so I cleanup some >> compiler warnings while I was at it to make sure I don't miss one). > > > I agree that it seems natural as an NSData category, but I also think we > need to avoid pollution of the basic headers/classes, so I don't think > the patch is a good idea. mhm... > IMO a more 'correct' patch would be to: > 1. Put the implementation in Source/Additions/GSCategories.m (and the > declaration in Headers/Additions/GNUstep/GSCategories.h) > 2. Mark the methods in GSMime.h as deprecated and to be removed in > version 1.17.0 > 3. Change GSMime.m and all files currently using the methods to use the > NSData methods and include GSCategories.h > I'm a bit confused... or I should have explained it better but I thought the patch did these things... well almost. I've also added the declarations to the NSData.h header because -base avoids including GSCategories.h declarations when building itself and relies on the extensions being declared in GNUstep's standard headers. I it was once explained to me that this was done to avoid having folks who merely target GNUstep from having to include the special headers. But maybe we should reconsider this approach and change remove the: /* The following ifndef prevents the categories declared in this file being * seen in GNUstep code. This is necessary because those category * declarations are also present in the header files for the corresponding * classes in GNUstep. The separate category declarations in this file * are only needed for software using the GNUstep Additions library * without the main GNUstep base library. */ #ifndef GNUSTEP in GSCategories.h But maybe you just mean that the method of deprecation isn't optimal. What I did is that I simply removed the old method declaration from the GSMime.h header but left the implementation which produces a warning when invoked before forwarding it to the NSData category. The warning also doesn't specify a specific version of when the implementation would be removed. 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). Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Testfarm Results
Hi GNUstep developers, David Ayers wrote: > Adam Fedor schrieb: >> Test results for GNUstep as of Mon Dec 3 06:34:10 EST 2007 >> If a particular system failed compilation, the logs for that system will >> be placed at ftp://ftp.gnustep.org/pub/testfarm >> >> If you would like to be a part of this automated testfarm, see >> http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F >> >> Fail Compile i386-unknown-freebsd6.3 Mon Dec 3 15:36:40 CST 2007 > > NSDecimalNumber.m: In function `-[NSDecimalNumber initWithBytes:objCType:]': > NSDecimalNumber.m:348: warning: implicit declaration of function `isinff' > ... > ../Source/./obj/libgnustep-base.so: undefined reference to `isinff' > gmake[2]: *** [obj/autogsdoc] Error 1 > gmake[1]: *** [autogsdoc.all.tool.variables] Error 2 > gmake[1]: Leaving directory > `/var/home/gstest/gnustep-testfarm/core/base/Tools' > gmake: *** [internal-all] Error 2 > > > Could someone with access to a FreeBSD system check whether I need to > define something special (akin to _GNU_SOURCE) to make isinff() visible, > or let me know of FreeBSD's C-Library simply does not provide isinff? On my FreeBSD 6.3-RC1 box, isinf() is a macro that supports both double and float (so does isnan()), and visible from , but there is no isinff(). I think it conforms to the ISO C standard according to this: http://www.opengroup.org/onlinepubs/009695399/functions/isinf.html I am not sure about isinff(). Regards, Yong-jhen. > > >> Success Compile i386-unknown-netbsdelf3.1 Mon Dec 3 03:57:12 CET 2007 >> Fail Compile sparc-sun-solaris2.7 Mon Dec 3 01:23:28 EST 2007 > > Here it seems that > > isnanf > isinf > isinff > > are all not visible. There must also be someway to expose the C99 macros. > > Cheers, > David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: RFC: en/decodeBase64 relocation
On 2007-12-02 21:32:17 + David Ayers <[EMAIL PROTECTED]> wrote: Hello everyone, Even though base64 encoding is primarily used with MIME processing, its usage does spring up here in related and unrelated scenarios. It also seems more natural as an NSData category to me. I'm wondering whether this patch: moving the implementation of GSMime en/decodeBase64: to an NSData en/decodeBase64 category would be considered too much of a name pollution issue wrt NSData. I've had this patch in my tree for some time now (had to clean it up a bit and check for new usage of the current method so I cleanup some compiler warnings while I was at it to make sure I don't miss one). I agree that it seems natural as an NSData category, but I also think we need to avoid pollution of the basic headers/classes, so I don't think the patch is a good idea. IMO a more 'correct' patch would be to: 1. Put the implementation in Source/Additions/GSCategories.m (and the declaration in Headers/Additions/GNUstep/GSCategories.h) 2. Mark the methods in GSMime.h as deprecated and to be removed in version 1.17.0 3. Change GSMime.m and all files currently using the methods to use the NSData methods and include GSCategories.h ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
Le jeudi 06 décembre 2007 à 12:43 +, Richard Frith-Macdonald a écrit : > Well it does ... unless the program crashes first :-) :) > Thanks ...looks like it's crashing while trying to find the callstack return > addresses. > > 1. Could you please let me know what signal is causing the crash ... this > code has a signal handler to trap segmentation violations caused by a known > bug in gcc, but maybe the gcc function to provide return addresses can crash > in ways other than a segmentation violation. gdb tells me : Program received signal SIGSEGV, Segmentation fault. > 2. Could you also try updating from svn ... I just recently added a check to > try to limit the number of return addresses we look up to 2 less than the > reported number of stack frames, in the hope of avoiding encountering the bug > in gcc's __builtin_return_address() function altogether. It may be that this > will have fixed your problem. Yep, I did an update and it works perfectly now ! Thanks a lot Richard, Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
On 2007-12-06 12:30:54 + Philippe Roussel <[EMAIL PROTECTED]> wrote: > Le jeudi 06 décembre 2007 à 10:59 +, Richard Frith-Macdonald a > écrit : >> On 2007-12-06 09:51:35 + Philippe Roussel <[EMAIL PROTECTED]> wrote: >>> Well, I have to disagree : see NSURL.m line 837. I want to type >>> http://philou:[EMAIL PROTECTED]/ but when parsing philou: NSURL thinks it's >>> a hostname followed by a port and is expecting a numeric value. >> >> My thought was ... Line 837 of NSURL.m is only reached when checking the >> port part of the URL, and since there is no port part in your example >> string, it can only be reached from parsing a different URL string. >> >> However, I just realised that you are probably actually talking about >> validating a whole set of URLs as you add a character at a time to the >> length ... 'h', then 'ht' then 'htt' then 'http' then 'http:' and so on. >> When you get to 'http://philou:' the code will be assuming that 'philou' is >> a host name because there is no '@' sign present to tell it that it's >> actually a username and password followed by a host. It therefore assumes >> that what comes after the colon is a port (and it's correct to do so, >> because that's what the RFCs tell us). > > Yes, sorry I wasn't clear enough. I'm using this to enable/disable the > "Ok" button of a dialog for each modificaton in a TextField. I just > didn't find another (easy) way to know if a String is a valid url. > > I know http://philou: isn't valid and I would like URLWithString: to > return nil as documented. Well it does ... unless the program crashes first :-) >>> My code used to function (NSURL URLWithString returning nil with a non >>> valid string) until I updated to trunk yesterday or two days ago. >> PS. -initWithString:relativeToURL: should only be exiting with an exception >> if you passed it a nil argument. All the other error checking just results >> in a nil value returned. This somewhat inconsistent behavior is copying >> the MacOS-X implementation behavior (I don't believe an initialisation >> method should ever raise an exception). I've modified the logging to >> refrain from printing the diagnostics unless debug is explicitly turtned >> on. >> >> Anyway, I can't see why any of this should cause a coredump ... perhaps you >> could print a stack trace in gdb to show where/why your app is dumping? > > Here it is (URLWithString is called with @"http://philou:c";) : > > #0 0xb7924c3d in GSPrivateStackAddresses () at NSDebug.m:1145 > #1 0xb7938c09 in -[NSException raise] (self=0x857e8c0, _cmd=0xb7b6c548) > at NSException.m:817 > #2 0xb793876e in +[NSException raise:format:arguments:] > (self=0xb7b6c340, _cmd=0xb7b6c530, name=0xb7b6c0e4, format=0xb7b9b11c, > argList=0xbfb7a150 "�z9\b\020O3\bH[L\b") at NSException.m:760 > #3 0xb79386a6 in +[NSException raise:format:] (self=0xb7b6c340, > _cmd=0xb7b9b5d0, name=0xb7b6c0e4, format=0xb7b9b11c) at > NSException.m:746 > #4 0xb79f26c1 in -[NSURL initWithString:relativeToURL:] > (self=0x85197d8, _cmd=0xb7b9b600, aUrlString=0x84c5b48, aBaseUrl=0x0) at > NSURL.m:850 > #5 0xb79f1bec in -[NSURL initWithString:] (self=0x85197d8, > _cmd=0xb7b9b5f8, aUrlString=0x84c5b48) at NSURL.m:619 > #6 0xb79f162d in +[NSURL URLWithString:] (self=0xb7b9b580, > _cmd=0x8077300, aUrlString=0x84c5b48) at NSURL.m:509 > #7 0x0805e3fc in -[iCalStoreDialog controlTextDidChange:] > (self=0x847fc10, _cmd=0xb7f29d08, notification=0x849a598) at > iCalStore.m:62 > #8 0xb796f151 in -[NSNotificationCenter _postAndRelease:] > (self=0x80bbe40, _cmd=0xb7b7af08, notification=0x849a598) at > NSNotificationCenter.m:1067 > #9 0xb796f6d8 in -[NSNotificationCenter > postNotificationName:object:userInfo:] (self=0x80bbe40, _cmd=0xb7ec94a8, > name=0xb7f46470,object=0x845d180, info=0x82df438) at > NSNotificationCenter.m:1126 > #10 0xb7cd9da8 in -[NSControl textDidChange:] (self=0x845d180, > _cmd=0xb7f29df8, aNotification=0x856cc08) at NSControl.m:567 > > [snip] > > It could be something wrong in my code but I haven't changed it in a > long time and it used to work fine. Thanks ...looks like it's crashing while trying to find the callstack return addresses. 1. Could you please let me know what signal is causing the crash ... this code has a signal handler to trap segmentation violations caused by a known bug in gcc, but maybe the gcc function to provide return addresses can crash in ways other than a segmentation violation. 2. Could you also try updating from svn ... I just recently added a check to try to limit the number of return addresses we look up to 2 less than the reported number of stack frames, in the hope of avoiding encountering the bug in gcc's __builtin_return_address() function altogether. It may be that this will have fixed your problem. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
Le jeudi 06 décembre 2007 à 10:59 +, Richard Frith-Macdonald a écrit : > On 2007-12-06 09:51:35 + Philippe Roussel <[EMAIL PROTECTED]> wrote: > > Well, I have to disagree : see NSURL.m line 837. I want to type > > http://philou:[EMAIL PROTECTED]/ but when parsing philou: NSURL thinks it's > > a hostname followed by a port and is expecting a numeric value. > > My thought was ... Line 837 of NSURL.m is only reached when checking the port > part of the URL, and since there is no port part in your example string, it > can only be reached from parsing a different URL string. > > However, I just realised that you are probably actually talking about > validating a whole set of URLs as you add a character at a time to the length > ... 'h', then 'ht' then 'htt' then 'http' then 'http:' and so on. > When you get to 'http://philou:' the code will be assuming that 'philou' is a > host name because there is no '@' sign present to tell it that it's actually > a username and password followed by a host. It therefore assumes that what > comes after the colon is a port (and it's correct to do so, because that's > what the RFCs tell us). Yes, sorry I wasn't clear enough. I'm using this to enable/disable the "Ok" button of a dialog for each modificaton in a TextField. I just didn't find another (easy) way to know if a String is a valid url. I know http://philou: isn't valid and I would like URLWithString: to return nil as documented. > > My code used to function (NSURL URLWithString returning nil with a non > > valid string) until I updated to trunk yesterday or two days ago. > > PS. -initWithString:relativeToURL: should only be exiting with an exception > if you passed it a nil argument. All the other error checking just results > in a nil value returned. This somewhat inconsistent behavior is copying the > MacOS-X implementation behavior (I don't believe an initialisation method > should ever raise an exception). I've modified the logging to refrain from > printing the diagnostics unless debug is explicitly turtned on. > > Anyway, I can't see why any of this should cause a coredump ... perhaps you > could print a stack trace in gdb to show where/why your app is dumping? Here it is (URLWithString is called with @"http://philou:c";) : #0 0xb7924c3d in GSPrivateStackAddresses () at NSDebug.m:1145 #1 0xb7938c09 in -[NSException raise] (self=0x857e8c0, _cmd=0xb7b6c548) at NSException.m:817 #2 0xb793876e in +[NSException raise:format:arguments:] (self=0xb7b6c340, _cmd=0xb7b6c530, name=0xb7b6c0e4, format=0xb7b9b11c, argList=0xbfb7a150 "�z9\b\020O3\bH[L\b") at NSException.m:760 #3 0xb79386a6 in +[NSException raise:format:] (self=0xb7b6c340, _cmd=0xb7b9b5d0, name=0xb7b6c0e4, format=0xb7b9b11c) at NSException.m:746 #4 0xb79f26c1 in -[NSURL initWithString:relativeToURL:] (self=0x85197d8, _cmd=0xb7b9b600, aUrlString=0x84c5b48, aBaseUrl=0x0) at NSURL.m:850 #5 0xb79f1bec in -[NSURL initWithString:] (self=0x85197d8, _cmd=0xb7b9b5f8, aUrlString=0x84c5b48) at NSURL.m:619 #6 0xb79f162d in +[NSURL URLWithString:] (self=0xb7b9b580, _cmd=0x8077300, aUrlString=0x84c5b48) at NSURL.m:509 #7 0x0805e3fc in -[iCalStoreDialog controlTextDidChange:] (self=0x847fc10, _cmd=0xb7f29d08, notification=0x849a598) at iCalStore.m:62 #8 0xb796f151 in -[NSNotificationCenter _postAndRelease:] (self=0x80bbe40, _cmd=0xb7b7af08, notification=0x849a598) at NSNotificationCenter.m:1067 #9 0xb796f6d8 in -[NSNotificationCenter postNotificationName:object:userInfo:] (self=0x80bbe40, _cmd=0xb7ec94a8, name=0xb7f46470, object=0x845d180, info=0x82df438) at NSNotificationCenter.m:1126 #10 0xb7cd9da8 in -[NSControl textDidChange:] (self=0x845d180, _cmd=0xb7f29df8, aNotification=0x856cc08) at NSControl.m:567 [snip] It could be something wrong in my code but I haven't changed it in a long time and it used to work fine. Thanks, Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
On 2007-12-06 09:51:35 + Philippe Roussel <[EMAIL PROTECTED]> wrote: > Le jeudi 06 décembre 2007 à 09:32 +, Richard Frith-Macdonald a > écrit : >> My guess is that you are misinterpreting what's happening. >> >> Probably the reason the NSLog() in the exception handler is not called is >> because the handler is not called because the exception is not ocurring in >> this piece of code. The exception message 'illegal character in port part' >> does not correspond to a URL for the form 'http://user:[EMAIL PROTECTED]' >> because >> such a URL has no port part, so it's presumably being raised because some >> otyher URL used elsewhere in the program has a port part containing an >> illegal character. > > Well, I have to disagree : see NSURL.m line 837. I want to type > http://philou:[EMAIL PROTECTED]/ but when parsing philou: NSURL thinks it's > a hostname followed by a port and is expecting a numeric value. My thought was ... Line 837 of NSURL.m is only reached when checking the port part of the URL, and since there is no port part in your example string, it can only be reached from parsing a different URL string. However, I just realised that you are probably actually talking about validating a whole set of URLs as you add a character at a time to the length ... 'h', then 'ht' then 'htt' then 'http' then 'http:' and so on. When you get to 'http://philou:' the code will be assuming that 'philou' is a host name because there is no '@' sign present to tell it that it's actually a username and password followed by a host. It therefore assumes that what comes after the colon is a port (and it's correct to do so, because that's what the RFCs tell us). > My code used to function (NSURL URLWithString returning nil with a non > valid string) until I updated to trunk yesterday or two days ago. PS. -initWithString:relativeToURL: should only be exiting with an exception if you passed it a nil argument. All the other error checking just results in a nil value returned. This somewhat inconsistent behavior is copying the MacOS-X implementation behavior (I don't believe an initialisation method should ever raise an exception). I've modified the logging to refrain from printing the diagnostics unless debug is explicitly turtned on. Anyway, I can't see why any of this should cause a coredump ... perhaps you could print a stack trace in gdb to show where/why your app is dumping? ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: [patch #6286] NSBezierPath encode/decode improperly implemented
Fred Kiefer schrieb:
> A few days ago I replied to a patch send in by Christopher Wojno:
>
> Fred Kiefer wrote:
>
>>Update of patch #6286 (project gnustep):
>>In your error message I can see that an NSKeyedArchiver gets used. As far as
>>I can see, your patch doesn't implement the missing keyed archiving for
>>NSBezierPath, so how does it help you?
>>
>>In my code NSBezierPathElement is always an enumeration, why would the
>>encoding stuff need the additional hint that it really is an enum? As far as I
>>can see there is no struct called NSBezierPathElement.
>>
>
>
> It turned out that it really makes a difference if we use
> @encode(NSBezierPathElement) or @encode(enum NSBezierPathElement). Could
> somebody explain this to me? Why isn't NSBezierPathElement resolved to
> an unsigned int?
Hello Fred,
an enum should be encoded as an int (as opposed to an unsigned int) on
most platforms (See NSComparisonResult for usage of negative values).
Yet there are platforms(/gcc options) for which small enums can be
stored in smaller signed base types.
But I do believe that:
typedef {
VAL1,
VAL2
} ENumType;
@encode(ENumType);
and
@encode(enum ENumType);
should always return the same string (on our platforms "i").
Cheers,
David
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
Le jeudi 06 décembre 2007 à 09:32 +, Richard Frith-Macdonald a écrit : > My guess is that you are misinterpreting what's happening. > > Probably the reason the NSLog() in the exception handler is not called > is because the handler is not called because the exception is not > ocurring in this piece of code. The exception message 'illegal > character in port part' does not correspond to a URL for the form > 'http://user:[EMAIL PROTECTED]' because such a URL has no port part, so it's > presumably being raised because some otyher URL used elsewhere in the > program has a port part containing an illegal character. Well, I have to disagree : see NSURL.m line 837. I want to type http://philou:[EMAIL PROTECTED]/ but when parsing philou: NSURL thinks it's a hostname followed by a port and is expecting a numeric value. My code used to function (NSURL URLWithString returning nil with a non valid string) until I updated to trunk yesterday or two days ago. I did an update 10 minutes ago and got a modification on NSException.m. Now the exception only logs NAME:NSGenericException REASON:illegal character in port part INFO:(nil) instead of the previous big blob but the problem remains. Philippe ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Exception handling with NSURL
On 2007-12-06 08:51:29 + Philippe Roussel <[EMAIL PROTECTED]>
wrote:
Hi all,
I'm trying to verify a string is a valid URL with the following :
- (void)controlTextDidChange:(NSNotification *)notification
{
NS_DURING
{
NSURL *storeUrl = [NSURL URLWithString:[url stringValue]];
[ok setEnabled:(storeUrl != nil)];
}
NS_HANDLER
{
NSLog([localException name]);
[ok setEnabled:NO];
}
NS_ENDHANDLER
}
When I enter an URL of the form http://user:[EMAIL PROTECTED], an exception is
raised (see below) when starting to enter the password because NSURL
is
expecting a numeric port (as in http://host:port). The thing is, the
exception isn't catched by NS_HANDLER (NSLog is never called) and the
application coredumps when I enter another caracter.
NAME:NSGenericException REASON:illegal
character in port part
Am I doing something wrong ?
My guess is that you are misinterpreting what's happening.
Probably the reason the NSLog() in the exception handler is not called
is because the handler is not called because the exception is not
ocurring in this piece of code. The exception message 'illegal
character in port part' does not correspond to a URL for the form
'http://user:[EMAIL PROTECTED]' because such a URL has no port part, so it's
presumably being raised because some otyher URL used elsewhere in the
program has a port part containing an illegal character.
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GNUstep Testfarm Results
Yong-Jhen Hong schrieb: > Hi GNUstep developers, > > David Ayers wrote: >> Adam Fedor schrieb: >>> Test results for GNUstep as of Mon Dec 3 06:34:10 EST 2007 >>> If a particular system failed compilation, the logs for that system will >>> be placed at ftp://ftp.gnustep.org/pub/testfarm >>> >>> If you would like to be a part of this automated testfarm, see >>> > http://wiki.gnustep.org/index.php/Developer_FAQ#How_can_I_take_part_with_a_GNUstep_autobuilder_for_the_testfarm.3F > >>> >>> Fail Compile i386-unknown-freebsd6.3 Mon Dec 3 15:36:40 CST 2007 >> >> NSDecimalNumber.m: In function `-[NSDecimalNumber > initWithBytes:objCType:]': >> NSDecimalNumber.m:348: warning: implicit declaration of function `isinff' >> ... >> ../Source/./obj/libgnustep-base.so: undefined reference to `isinff' >> gmake[2]: *** [obj/autogsdoc] Error 1 >> gmake[1]: *** [autogsdoc.all.tool.variables] Error 2 >> gmake[1]: Leaving directory >> `/var/home/gstest/gnustep-testfarm/core/base/Tools' >> gmake: *** [internal-all] Error 2 >> >> >> Could someone with access to a FreeBSD system check whether I need to >> define something special (akin to _GNU_SOURCE) to make isinff() visible, >> or let me know of FreeBSD's C-Library simply does not provide isinff? > > On my FreeBSD 6.3-RC1 box, isinf() is a macro that supports both > double and float (so does isnan()), and visible from , > but there is no isinff(). > > I think it conforms to the ISO C standard according to this: > > http://www.opengroup.org/onlinepubs/009695399/functions/isinf.html > > I am not sure about isinff(). Thanks... indeed I was mistaken that isinff() is part of C99. I could have used isinf() for floats also as it there seem to be sizeof checks within that macro to insure that no implicit promotion takes place. I've currently fellback to fpclassify since I thought that would be more portable, but it infact it's as portable as the isinf/isnan macros (ie. C99). What /might/ have helped on Solaris (or at least newer Solaris versions) is the "#define _ISO99_SOURCE". But the current code should also work for FreeBSD. Cheers, David ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Exception handling with NSURL
Hi all,
I'm trying to verify a string is a valid URL with the following :
- (void)controlTextDidChange:(NSNotification *)notification
{
NS_DURING
{
NSURL *storeUrl = [NSURL URLWithString:[url stringValue]];
[ok setEnabled:(storeUrl != nil)];
}
NS_HANDLER
{
NSLog([localException name]);
[ok setEnabled:NO];
}
NS_ENDHANDLER
}
When I enter an URL of the form http://user:[EMAIL PROTECTED], an exception is
raised (see below) when starting to enter the password because NSURL is
expecting a numeric port (as in http://host:port). The thing is, the
exception isn't catched by NS_HANDLER (NSLog is never called) and the
application coredumps when I enter another caracter.
NAME:NSGenericException REASON:illegal
character in port part STACK:("{pointer = 0xb78847be;}", "{pointer =
0xb78846f6;}", "{pointer = 0xb793e50f;}", "{pointer = 0xb793dc1c;}",
"{pointer = 0xb793d65d;}", "{pointer = 0x805e07f;}", "{pointer =
0xb78bb181;}", "{pointer = 0xb78bb708;}", "{pointer = 0xb7c25d88;}",
"{pointer = 0xb7d1a37a;}", "{pointer = 0xb78bb181;}", "{pointer =
0xb78bb708;}", "{pointer = 0xb78bb5bd;}", "{pointer = 0xb7d8e7ab;}",
"{pointer = 0xb7d8d0bc;}", "{pointer = 0xb7c6ac34;}", "{pointer =
0xb7c6a8b4;}", "{pointer = 0xb7cc128c;}", "{pointer = 0xb7d974c2;}",
"{pointer = 0xb7d45ab2;}", "{pointer = 0xb7bc4f4a;}", "{pointer =
0xb7bc476b;}", "{pointer = 0xb7bc4306;}", "{pointer = 0x805deb8;}",
"{pointer = 0x805f741;}", "{pointer = 0x805d61a;}", "{pointer =
0xb72e3437;}", "{pointer = 0xb7975496;}", "{pointer = 0xb7975865;}",
"{pointer = 0xb7bc571a;}", "{pointer = 0xb7c26431;}", "{pointer =
0xb7bfca65;}", "{pointer = 0xb7bf68b0;}", "{pointer = 0xb7c2687b;}",
"{pointer = 0xb7bf2555;}", "{pointer = 0xb7d45ab2;}", "{pointer =
0xb7bc4f4a;}", "{pointer = 0xb7bc3b38;}", "{pointer = 0xb7ba6151;}",
"{pointer = 0x80670ca;}", "{pointer = 0xb75f4050;}", "{pointer =
0x804b2f1;}")
Am I doing something wrong ?
Thanks,
Philippe
___
Gnustep-dev mailing list
Gnustep-dev@gnu.org
http://lists.gnu.org/mailman/listinfo/gnustep-dev
