cocoaforge

It seems that all the frameworks in Leopard are compiled for 4 architectures:
ppc
i386
ppc64
x86_64

You can see this by typing this in the terminal:
file /System/Library/Frameworks/QTKit.framework/QTKit

Also, the lib's appear to be the same way:
file /usr/lib/libcrypto.dylib

Will the Growl Framework be released this way soon?
Is there much demand for this?
Will there be much demand for this soon?

Actually, most of the system frameworks are 8 way fat binaries because they also include garbage collected and non-GC variants as well.

To answer your questions:

- No.
- Not really, 64 bit is meant for those who need to address large data sets in memory and hit limitations in the 32 bit address space. If you haven't yet, this doesn't concern you.
- Only insofar as people buy into buzzwords. It's primarily used in scientific applications and production style applications.

bgannin wrote:Actually, most of the system frameworks are 8 way fat binaries because they also include garbage collected and non-GC variants as well.

That is not actually true. The system libraries on Leopard are 4 way. So long as you implement the appropriate ref counting code and have the compiler insert memory barriers for the collector the same code can run in either mode. That is what all of the system libraries do.

Now, there is no way to compile code with appropriate memory barriers and also have it work on Tiger. That means if you need a library to support back to Tiger you need to build a separate binary for Leopard, even though you can compile a single executable that supports GC and non-GC on Leopard. Technically both of those binaries are for the same architecture, so I do not believe they can be stored in the same fat binary.

Anyway, I would really like a GC aware Growl, but I don't envy anyone who maintains frameworks and has to deal with backwards compatibility with Tiger the headaches that it entails to enable GC.

I've recompiled the framework myself. Very easy, barely any changes. X86 64 works. I've not tested Carbon or PPC 64 though.

Basically, I just removed the seg1addr arg to ld, turned off "All Symbols Hidden by Default" (it seems Objc-2 can now hide classes) and then make a change to the carbon header to insure "unsigned" was actually an "unsigned int" (don't think it would have changed, but best to be explicit").

$ svn diff -r 4702
Index: Growl.xcodeproj/project.pbxproj
===================================================================
--- Growl.xcodeproj/project.pbxproj (revision 4702)
+++ Growl.xcodeproj/project.pbxproj (working copy)
@@ -4068,12 +4068,14 @@
95EE27880855AA6C0045DB39 /* Development */ = {
isa = XCBuildConfiguration;
buildSettings = {
+ ARCHS = i386;
DYLIB_COMPATIBILITY_VERSION = 1;
DYLIB_CURRENT_VERSION = 1;
FRAMEWORK_VERSION = A;
GCC_PRECOMPILE_PREFIX_HEADER = YES;
GCC_PREFIX_HEADER = Framework/Source/GrowlFramework_Prefix.pch;
- GCC_SYMBOLS_PRIVATE_EXTERN = YES;
+ GCC_SYMBOLS_PRIVATE_EXTERN = NO;
+ GCC_THREADSAFE_STATICS = YES;
INFOPLIST_FILE = "Framework/Resources/Growl.framework-Info.plist";
INFOPLIST_PREFIX_HEADER = "$(TARGET_BUILD_DIR)/include/SVNRevision.h";
INFOPLIST_PREPROCESS = YES;
@@ -4084,8 +4086,6 @@
"-lobjc",
"-sub_library",
libobjc,
- "-seg1addr",
- 0xC0000000,
);
PRODUCT_NAME = Growl;
REZ_RESOURCE_MAP_READ_ONLY = YES;
@@ -4096,6 +4096,12 @@
95EE27890855AA6C0045DB39 /* Deployment */ = {
isa = XCBuildConfiguration;
buildSettings = {
+ ARCHS = (
+ ppc64,
+ i386,
+ ppc,
+ x86_64,
+ );
DYLIB_COMPATIBILITY_VERSION = 1;
DYLIB_CURRENT_VERSION = 1;
FRAMEWORK_VERSION = A;
@@ -4105,7 +4111,8 @@
NDEBUG,
NS_BLOCK_ASSERTIONS,
);
- GCC_SYMBOLS_PRIVATE_EXTERN = YES;
+ GCC_SYMBOLS_PRIVATE_EXTERN = NO;
+ GCC_THREADSAFE_STATICS = YES;
INFOPLIST_FILE = "Framework/Resources/Growl.framework-Info.plist";
INFOPLIST_PREFIX_HEADER = "$(TARGET_BUILD_DIR)/include/SVNRevision.h";
INFOPLIST_PREPROCESS = YES;
@@ -4116,8 +4123,6 @@
"-lobjc",
"-sub_library",
libobjc,
- "-seg1addr",
- 0xC0000000,
);
PRODUCT_NAME = Growl;
REZ_RESOURCE_MAP_READ_ONLY = YES;
Index: Framework/Source/GrowlApplicationBridge-Carbon.h
===================================================================
--- Framework/Source/GrowlApplicationBridge-Carbon.h (revision 4702)
+++ Framework/Source/GrowlApplicationBridge-Carbon.h (working copy)
@@ -292,7 +292,7 @@

/* These bits are not used in Growl 0.6. Set them to 0.
*/
- unsigned reserved: 31;
+ unsigned int reserved: 31;

/* When the sticky bit is clear, in most displays,
* notifications disappear after a certain amount of time. Sticky
@@ -305,7 +305,7 @@
* notification to be sticky or non-sticky, in which case the sticky bit
* in the notification will be ignored.
*/
- unsigned isSticky: 1;
+ unsigned int isSticky: 1;

/* If this is not <code>NULL</code>, and your click callback
* is not <code>NULL</code> either, this will be passed to the callback

brianb wrote:I've recompiled the framework myself. Very easy, barely any changes. X86 64 works. I've not tested Carbon or PPC 64 though.

I'm glad this worked for you but we'll be taking a graduated approach to releasing upgrades to framework variants due to the scope of change that we are accountable for and need to insure. The first variant I'd like to see us release is a garbage-collected one.

Actually, it's easier to offer 64-bit support than garbage collection. For gc, we would need to ship two different versions, one for 10.5+ and one for previous versions of Mac OS X.

As for 64-bit, we can just enable ppc64 and x86_64 for Growl.framework and it should work. Growl-WithInstaller.framework can't be ported in its current form because it uses Carbon UI stuff which is not present in 64-bit Mac OS X.

IngmarStein wrote:Actually, it's easier to offer 64-bit support than garbage collection. For gc, we would need to ship two different versions, one for 10.5+ and one for previous versions of Mac OS X.

As for 64-bit, we can just enable ppc64 and x86_64 for Growl.framework and it should work. Growl-WithInstaller.framework can't be ported in its current form because it uses Carbon UI stuff which is not present in 64-bit Mac OS X.

That's your opinion Given that 64-bit actually introduces a new runtime and forcibly deprecates a swath of API, I find it a more problematic one than reviewing memory management.

Growl doesn't have to be 64bit, just the framework. That greatly limits the code scope and it is easier than GC support.

Our road map is gc first. That's the more pressing matter. It doesn't matter whether one is more difficult than the other. More people are going to need gc in the near future than they are going to need 64 bit.

Yes, but Scientific applications use Growl! OsiriX uses Growl, and currently, we cannot use Growl in our 64-bit version. Please add 64-bit support! It's much more important than GC, in my opinion. Thanks for this framework !

bgannin wrote:Actually, most of the system frameworks are 8 way fat binaries because they also include garbage collected and non-GC variants as well.

To answer your questions:

- No.
- Not really, 64 bit is meant for those who need to address large data sets in memory and hit limitations in the 32 bit address space. If you haven't yet, this doesn't concern you.
- Only insofar as people buy into buzzwords. It's primarily used in scientific applications and production style applications.

Feel free to submit a patch then.

Tick: I submitted one above.

Hell, the carbon change I made isn't even necessary (confirmed).

Did you exercise the entire Carbon framework in 64 bit to confirm that every aspect works (not just whatever parts you use)? That's what will get the patch accepted. Unnecessary changes shouldn't be included, and it's handier if you actually submit it as a text file diff to the mailing list instead of an inline part of a forum post.

bgannin wrote: - Not really, 64 bit is meant for those who need to address large data sets in memory and hit limitations in the 32 bit address space. If you haven't yet, this doesn't concern you.
- Only insofar as people buy into buzzwords. It's primarily used in scientific applications and production style applications.

On PPC or sparc this would be true. x86 is peculiar in that the architecture has always been register-starved compared to other chips. When AMD defined the x86_64 ISA, they not only increased the size of each register to 64-bits, but they also doubled the number of (general purpose and SSE) registers, which has a non-trivial impact on code performance. I've compared code compiled with gcc in 32 and 64-bit mode, and seen 10-20% improvements in speed on the same system.

I don't want to tell people how to spend their development time, but I just wanted to point out that application developers have other reasons to go 64-bit beyond buzzword compliance.

volsung wrote:

bgannin wrote: - Not really, 64 bit is meant for those who need to address large data sets in memory and hit limitations in the 32 bit address space. If you haven't yet, this doesn't concern you.
- Only insofar as people buy into buzzwords. It's primarily used in scientific applications and production style applications.

On PPC or sparc this would be true. x86 is peculiar in that the architecture has always been register-starved compared to other chips. When AMD defined the x86_64 ISA, they not only increased the size of each register to 64-bits, but they also doubled the number of (general purpose and SSE) registers, which has a non-trivial impact on code performance. I've compared code compiled with gcc in 32 and 64-bit mode, and seen 10-20% improvements in speed on the same system.

I don't want to tell people how to spend their development time, but I just wanted to point out that application developers have other reasons to go 64-bit beyond buzzword compliance.

You state "code" that's seen improvement - I have a feeling these are benchmarkable examples. Does a 64-bit, fully framework consuming app exhibit such a gain across the board from switching? No. It's a directed change that is not a performance panacea.

This topic has gone on long enough. We're doing gc first, then 64 bit later. That's just how it's going to be.

Sorry, but these speed improvements are real for real application. We measured a gain of 15% in our 3D rendering application, OsiriX.

64-bit is the future for memory management AND performances...

bgannin wrote:

volsung wrote:

bgannin wrote:
I don't want to tell people how to spend their development time, but I just wanted to point out that application developers have other reasons to go 64-bit beyond buzzword compliance.

You state "code" that's seen improvement - I have a feeling these are benchmarkable examples. Does a 64-bit, fully framework consuming app exhibit such a gain across the board from switching? No. It's a directed change that is not a performance panacea.

OsiriX wrote:S64-bit is the future for memory management AND performances...

But not the immediate future for Growl. If you want 64 bit, build it yourself until we provide it. It won't be supported until we provide it.

bgannin wrote:

volsung wrote:

bgannin wrote: - Not really, 64 bit is meant for those who need to address large data sets in memory and hit limitations in the 32 bit address space. If you haven't yet, this doesn't concern you.
- Only insofar as people buy into buzzwords. It's primarily used in scientific applications and production style applications.

On PPC or sparc this would be true. x86 is peculiar in that the architecture has always been register-starved compared to other chips. When AMD defined the x86_64 ISA, they not only increased the size of each register to 64-bits, but they also doubled the number of (general purpose and SSE) registers, which has a non-trivial impact on code performance. I've compared code compiled with gcc in 32 and 64-bit mode, and seen 10-20% improvements in speed on the same system.

I don't want to tell people how to spend their development time, but I just wanted to point out that application developers have other reasons to go 64-bit beyond buzzword compliance.

You state "code" that's seen improvement - I have a feeling these are benchmarkable examples. Does a 64-bit, fully framework consuming app exhibit such a gain across the board from switching? No. It's a directed change that is not a performance panacea.

Who said it was? Seriously, I'm just trying to provide a little insight to why people are interested in 64-bit on x86, and it isn't just because they heard that 64 was a larger number than 32.

Growl devs have finite time, and should allocate it accordingly. gc first, 64-bit second sounds fine. Mac development will not halt because some 64-bit app can't use Growl for a few months.