Re: Will gnustep support the new xib format of Xcode 5
Le 19.08.2013 23:39, Gregory Casamento a écrit : Yes, I will be working on support for it. Right now GNUsteps libraries support XIB files, but Gorm itself doesnt. I am working on XIB support for the current version of the format. The XML you showed doesnt seem significantly different, though I need more information to determine if we can support it Don't understand why you say Gorm presently doesn't support XIB because because it's possible to open one xib file and see what it looks like. Last time I tried Gorm what was missing was the possibility to save a xib. While I am talking about xib please find a small video showing what I was able to do by translating GNUstep implementation into c# : www.smartmobili.com/downloads/XibBuilder.mkv. The video shows a xib viewer that allow to load xib file (AppKit only) and display them. The UI rendering is done in WPF but the business logic behind and the object creation is using GNUstep implementation. The GNUStep translation in c# is available here : https://github.com/smartmobili/CocoaBuilder/tree/master/XibParser This project was at the beginning a just for fun project but now it could be consider as a proof of concept of a managed GNUstep. If I still have time it would be interesting to go further and to also implement the UI rendering but to do it I would need to change the way I have done the translation and it implies a lot of work. I am also working on an objc rewriter using clang that would allow to translate GNUstep files (objc) into c# but I have some hard time with the translation of message calls. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Size of NSInteger/NSUInteger/CFIndex
I'm re-writing the CoreBase string formatting function (printf with %@ support) and while going through the printf(), Apple docs and other sources on the internet I ran across a potential problem with some of the assumptions made when defining these types. I understand that despite being very portable, GNUstep isn't made to work on all platforms, but I'm still going to use an unlikely platform as example... Anyway, in the Apple docs, they have: typedef long NSInteger; typedef unsigned long NSUInteger typedef long CFIndex; Yet, the discussion says: When building 32-bit applications, NSInteger is a 32-bit integer. A 64-bit application treats NSInteger as a 64-bit integer. This is true on LP64 platforms but not on any other platform. The problem that I see here is that the Apple docs about string formatting say that if you want to format a NSInteger/NSUInteger/CFIndex you should use '%ld' or '%lu'. GNUstep, on the other hand, defines these values as intptr_t/uintptr_t, which in my opinion is wrong. We essentially assume these types are as long as a pointer, which is true if you assume LP64. However, this assumption is not true for a cross-platform library. Lastly, I was browsing the web and came across this ( http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html) where int is 16-bits, long is 32-bits and intptr_t is 16-bits. I realize AVR is not a target, but I just wanted to use it as another example where long is not equivalent to intptr_t. And who known, someone might want to use it in the future. I would like to suggest typedef'ing NSInteger/NSUInteger/CFIndex as long. That way we can correctly format these integers across all platforms supported by GNUstep. Stef ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Size of NSInteger/NSUInteger/CFIndex
Hey Stef, I think what GNUstep is doing is OK... On 2013-08-20, at 3:34 PM, Stefan Bidi stefanb...@gmail.com wrote: I'm re-writing the CoreBase string formatting function (printf with %@ support) and while going through the printf(), Apple docs and other sources on the internet I ran across a potential problem with some of the assumptions made when defining these types. I understand that despite being very portable, GNUstep isn't made to work on all platforms, but I'm still going to use an unlikely platform as example... Anyway, in the Apple docs, they have: typedef long NSInteger; typedef unsigned long NSUInteger typedef long CFIndex; Yet, the discussion says: When building 32-bit applications, NSInteger is a 32-bit integer. A 64-bit application treats NSInteger as a 64-bit integer. This is true on LP64 platforms but not on any other platform. It's tricky, because we don't have a definitive specification. I don't think the typedef long NSInteger mentioned in the docs is the final/proper definition of NSInteger. For example, on OS X 10.8, NSInteger can be defined as 'int' under some circumstances. The problem that I see here is that the Apple docs about string formatting say that if you want to format a NSInteger/NSUInteger/CFIndex you should use '%ld' or '%lu'. This is from a table in String Programming Guide, right? I think you may have missed the Considerations column which says to cast the value to a long when using the %ld format specifier. This seems to be the accepted interpretation on stackoverflow as well: http://stackoverflow.com/questions/4405006/nslog-specifier-for-nsinteger GNUstep, on the other hand, defines these values as intptr_t/uintptr_t, which in my opinion is wrong. We essentially assume these types are as long as a pointer, which is true if you assume LP64. However, this assumption is not true for a cross-platform library. Lastly, I was browsing the web and came across this (http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html) where int is 16-bits, long is 32-bits and intptr_t is 16-bits. I realize AVR is not a target, but I just wanted to use it as another example where long is not equivalent to intptr_t. And who known, someone might want to use it in the future. I would like to suggest typedef'ing NSInteger/NSUInteger/CFIndex as long. That way we can correctly format these integers across all platforms supported by GNUstep. Hope my point addresses your concern. Cheers, Eric___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Size of NSInteger/NSUInteger/CFIndex
Ah, thanks. I remember I brought this up a while ago when I first wrote the formatting code and ended up with CFIndex equivalent to long, but couldn't remember if that was correct or not. Thanks for clarifying. On Tue, Aug 20, 2013 at 6:29 PM, Eric Wasylishen ewasylis...@gmail.comwrote: Hey Stef, I think what GNUstep is doing is OK... On 2013-08-20, at 3:34 PM, Stefan Bidi stefanb...@gmail.com wrote: I'm re-writing the CoreBase string formatting function (printf with %@ support) and while going through the printf(), Apple docs and other sources on the internet I ran across a potential problem with some of the assumptions made when defining these types. I understand that despite being very portable, GNUstep isn't made to work on all platforms, but I'm still going to use an unlikely platform as example... Anyway, in the Apple docs, they have: typedef long NSInteger; typedef unsigned long NSUInteger typedef long CFIndex; Yet, the discussion says: When building 32-bit applications, NSInteger is a 32-bit integer. A 64-bit application treats NSInteger as a 64-bit integer. This is true on LP64 platforms but not on any other platform. It's tricky, because we don't have a definitive specification. I don't think the typedef long NSInteger mentioned in the docs is the final/proper definition of NSInteger. For example, on OS X 10.8, NSInteger can be defined as 'int' under some circumstances. The problem that I see here is that the Apple docs about string formatting say that if you want to format a NSInteger/NSUInteger/CFIndex you should use '%ld' or '%lu'. This is from a table in String Programming Guide, right? I think you may have missed the Considerations column which says to cast the value to a long when using the %ld format specifier. This seems to be the accepted interpretation on stackoverflow as well: http://stackoverflow.com/questions/4405006/nslog-specifier-for-nsinteger GNUstep, on the other hand, defines these values as intptr_t/uintptr_t, which in my opinion is wrong. We essentially assume these types are as long as a pointer, which is true if you assume LP64. However, this assumption is not true for a cross-platform library. Lastly, I was browsing the web and came across this ( http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html) where int is 16-bits, long is 32-bits and intptr_t is 16-bits. I realize AVR is not a target, but I just wanted to use it as another example where long is not equivalent to intptr_t. And who known, someone might want to use it in the future. I would like to suggest typedef'ing NSInteger/NSUInteger/CFIndex as long. That way we can correctly format these integers across all platforms supported by GNUstep. Hope my point addresses your concern. Cheers, Eric ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Size of NSInteger/NSUInteger/CFIndex
On 20 Aug 2013, at 22:34, Stefan Bidi stefanb...@gmail.com wrote: I'm re-writing the CoreBase string formatting function (printf with %@ support) and while going through the printf(), Apple docs and other sources on the internet I ran across a potential problem with some of the assumptions made when defining these types. I understand that despite being very portable, GNUstep isn't made to work on all platforms, but I'm still going to use an unlikely platform as example... Anyway, in the Apple docs, they have: typedef long NSInteger; typedef unsigned long NSUInteger typedef long CFIndex; Yet, the discussion says: When building 32-bit applications, NSInteger is a 32-bit integer. A 64-bit application treats NSInteger as a 64-bit integer. From all my reading, I think the line immediately above is closest to a statement of what the NSInteger/NSUInteger types are for ... to portably support the situation where you want an integer big enough to store a pointer, when the memory model may (like LP64) have a default integer size which is not big enough. This is true on LP64 platforms but not on any other platform. The problem that I see here is that the Apple docs about string formatting say that if you want to format a NSInteger/NSUInteger/CFIndex you should use '%ld' or '%lu'. they also say you have to cast the value to be a long or unsigned long. I prefer to stick to the posix standard for this and use the PRIdPTR and PRIuPTR macros. Both formatting options work, both are ugly :-( IO find the posix macros a bit uglier, but they do have the advantages of being a bit shorter than the ld/lu format combined with the cast, and being pretty explicit about what the argument type actually is. GNUstep, on the other hand, defines these values as intptr_t/uintptr_t, which in my opinion is wrong. We essentially assume these types are as long as a pointer, which is true if you assume LP64. However, this assumption is not true for a cross-platform library. The point about using intptr_t/uintptr_t is precisely that it doesn't assume that a long is the size of a pointer, so it's a portable declaraction for NSInteger/NSUInteger. Lastly, I was browsing the web and came across this (http://www.nongnu.org/avr-libc/user-manual/group__avr__stdint.html) where int is 16-bits, long is 32-bits and intptr_t is 16-bits. I realize AVR is not a target, but I just wanted to use it as another example where long is not equivalent to intptr_t. And who known, someone might want to use it in the future. I would like to suggest typedef'ing NSInteger/NSUInteger/CFIndex as long. That way we can correctly format these integers across all platforms supported by GNUstep. I think you are understanding this the wrong way round , because you are reading the typedefs rather than the documentation. NSInteger and NSUInteger are not supposed to be 'long', they are supposed to be pointer sized; 32bit an a 32bit platform and 64bit on a 64bit platform. If you had a 64bit platform with a 128bit long, NSInteger would be 64bit, not 128bit. ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
