Re: NSString bug with test and really dodgy patch.
On Oct 3, 2012, at 09:53, Richard Frith-Macdonald wrote: > > So I'm not sure what to do ... the C standards have changed from working with > characters to working with bytes (which is good), Well, no. In the C standard, "character" generally means the same thing as "byte" (i.e., a value that can fit in a char). In point of fact, the standard provides two conflicting normative definitions of "character" (one marked , the other ), but in the specification [f]printf() it seems character = byte is what is meant. Both the C99 and C11 final drafts have a footnote saying "No special provisions are made for multibyte characters." The sentence "In no case is a partial multibyte character written." only applies to %ls format, i.e. when converting a wchar_t* string into a possibly multi-byte sequence for a char* string. The closest analogue to NSString formatting is using %s in [f]wprintf(). In this case, characters (i.e., bytes) from the string are converted "as if by repeated calls to the mbrtowc function" (with sane initial state), and the precision limits the number of wide characters to be written. This is unproblematic because wchar_ts are required to be complete code units, but Foundation unichars can be UTF-16 surrogates, so this still doesn't resolve the issue. In summary, "figure out what Cocoa does." :-) -- Jens Ayton ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Pixel-aligned autoresizing
On Jul 6, 2011, at 10:32, Fred Kiefer wrote: > > Basically wee need to ensure that all drawing operations that are > initiated by the gui drawing code get pixel aligned. Somebody will have > to test whether this is true for all drawing operations, that is, when I > use an NSBezierPath with fractional coordinates to draw into a NSView, > will the result be blurred? Yes, Cocoa NSBezierPath supports subpixel positioning. In fact, the most common question from beginners is why one-pixel rectangles at integer coordinates are drawn two pixels wide, and this is the answer. Developers writing custom views are expected to use -centerScanRect: and related coordinate transform functions to ensure grid-aligned drawing under transformation and UI scaling, and I assume the standard views do too. -- Jens Ayton ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: GSIMap
On Jun 10, 2011, at 15:23, David Chisnall wrote: > > In that case, someone should tell Apple: as I said in the original post, this > contract is not honoured by all of their classes. Both Apple, and > LanguageKit's closure implementations return a different object in response > to -retain if the block is allocated on the stack. Not true. Under OS X, retaining a block on the stack does nothing; -copy must be used. This is both the documented and observed behaviour. There are two reasons for this: 1) -retain is a no-op under garbage collection, but blocks still need to be copied to the heap; 2) it would violate the contract of -retain as per the NSObject protocol documentation. -- Jens Ayton ___ Gnustep-dev mailing list Gnustep-dev@gnu.org https://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: NSNumber Bug I can't fix
For reference, under Mac OS X 10.6.6: 2 compare: nan = NSOrderedDescending nan compare: 2 = NSOrderedAscending nan compare: nan = NSOrderedSame 2 isEqual: nan = NO nan isEqual: n = NO nan isEqual: nan = YES Just for fun, I tried it with [NSNumber numberWithDouble:INFINITY] instead of 2: inf compare: nan = NSOrderedDescending nan compare: inf = NSOrderedAscending -inf compare: nan = NSOrderedAscending nan compare: -inf = NSOrderedDescending -- Jens Ayton ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Text Antialising bug [Re: GNOME Theme Improvements....]
On Jan 1, 2011, at 22:17, David Chisnall wrote: > > On 1 Jan 2011, at 21:22, Banlu Kemiyatorn wrote: >> >> Looks like low quality jpeg compression to me. > > Except that the screenshot is a png... There are severe haloing artefacts around all edges in that picture, not just text. There's also a very faint, blurred grid of about 30x30 px squares (typically an effect of buggy sampling code), but little to no noise. It looks more like a sharpening filter than JPEG artefacts. -- Jens Ayton ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Is our name confusing people....
On Nov 20, 2010, at 19:13, Germán Arias wrote: > > I think the grey screenshot is necessary because this show the OpenStep > specifications (maybe update it). From time to time, one should pause to ask an obvious question. Such as: what are the odds that anyone, ever, visits gnustep.org being unfamiliar with the project but interested in conformance to OpenStep specifications? -- Jens Ayton ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compiler warnings building GNUstep gui
On Apr 6, 2010, at 13:03, David Chisnall wrote: > On 6 Apr 2010, at 09:24, Fred Kiefer wrote: >> >> NSRulerMarker.m:189: warning: ‘-retain’ not found in protocol(s) > > I see this a lot in code ported from OS X. I'm not sure exactly why it's an > error for us and not on OS X, but all of the Cocoa protocols are treated as > conforming to the NSObject protocol (I've not checked if they explicitly do, > or if the compiler just pretends that they do). It's explicit. -- Jens Ayton ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Grand Central
On Jun 14, 2009, at 14:53, Pete French wrote: http://images.apple.com/macosx/technology/docs/GrandCentral_TB_brief_20090608.pdf Interesting - that ^{ syntax to describe a block is somewhat ugly, and it doesnt give any deats of how you associate data with a block (which is necessary if you want to get rid of locks). There are two ways to pass data into blocks: constant copies from the parent scope, and mutable access to "block variables" in the parent scope (the latter makes blocks true closures). Here is a simple example: typedef int (^IntIntBlock)(int); IntIntBlock MakeExampleThing(int initial, int delta) { __block int accum = initial; int (^block)(int) = ^(int i) { return accum += i + delta; }; return Block_copy(block); } In the block created above, accum is a block variable, and delta is a const copy. If MakeExampleThing() is called twice, they get separate copies of accum, so there's your data associated with the block. If two blocks were created in the same function, both referring to accum, they would share it. int main(void) { int (^a)(int) = MakeExampleThing(5, 2); int (^b)(int) = MakeExampleThing(1, 0); printf("%i\n", a(3)); // prints 10 printf("%i\n", b(1)); // prints 2 Block_release(a); Block_release(b); return 0; } The block runtime is set up to allow blocks to be ObjC objects, so that Block_copy() and Block_release() can be replaced with retain and release messages. (Block_copy() is conceptually a retain operation, although it actually does copy in the above example because the block is initially created on the stack.) In case the new syntax and manual memory management overhead gets in the way in the above code, here's a Javascript equivalent: function MakeExampleThing(initial, delta) { return function(i) { return initial += i + delta; } } I can't work out if GCD is supposed to be an extension for OSX or an extension to Objective-C itself. Obviously the block syntax requiures a language extension, but how do the bits fit together from there onward ? Other than blocks, as far as I can see (I don't have Snow Leopard seeds) it's "just" a library and an optimized thread scheduler. -- Jens Ayton ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: ABI Compatibility (was Re: Installation woes for the average user...)
On May 21, 2009, at 11:47, David Chisnall wrote: Only half of this is true. Apple only ships one version of its frameworks. Each framework, however, contains different versions of the libraries. You may have noticed all of the OS X version macros in the headers. Each of those defines the parts of the interface that are visible in a particular version of the framework, but they are also used when compiling. Each version of OS X has a Foundation.framework containing several libFoundation.dylib files, one compiled for compatibility with each previous version. Oh, really? Have you taken the time to actually look? ;-) The bundle structure used for frameworks in OS X is specifically designed to allow this (except the library binary is called Foundation, not libFoundation.dylib), but it isn’t used much, if at all. The Foundation framework, for instance, does not use this method, and neither does CoreFoundation (which implements the most fundamental Foundation classes). In practice, the differences between different API versions is handled entirely using runtime checks. This can be seen in the public CFLite source code (see http://www.opensource.apple.com/ - no longer requires an account). The 10.4 versions of CFLite include the real implementation of the version checking function, _CFExecutableLinkedOnOrAfter(); 10.5 versions only have a stub. The problem of fragile ivars is handled (in the 32-bit runtime) by not changing class layouts, or changing them but keeping sizes unchanged. -- Jens Ayton ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev
Re: Compatibility breakage involved in upgrading to the MacOS-X 10.5 API
On Feb 22, 2009, at 13:50, David Chisnall wrote: I suspect the bigger problem will be the CGFloat type, which is now used all over Cocoa. I really don't understand the reason for this change. It's float on 32-bit and 64-bit on 64-bit platforms, which almost sounds sensible until you remember that 32-bit and 64-bit floats are both computed using the 80-bit x87 unit on 32-bit x86 and so are the same speed, but are computed with the SSE unit on x86-64 and so calculations on doubles are often slower than the equivalent calculations on floats. If anything, the opposite definitions would make more sense for the architectures that Apple supports (especially since most GPUs still can't handle doubles sensibly, and a lot of the geometry calculations that use these types will probably end up being offloaded to the GPU in future versions). Actually, the default for OS X programs is to use SSE in 32-bit builds as well. Changing to 64-bit types is bad for performance in general, not just for floating-point values. Increased flexibility is generally felt to be worth it. I suspect the relevant people felt it would be short- sighted not to take advantage of this ABI change to switch to doubles just because of minor limitations of current hardware; after all, the 128-bit transition won't happen for another four or five decades, while double-capable GPUs could easily be widespread in four or five years. -- Jens Ayton ___ Gnustep-dev mailing list Gnustep-dev@gnu.org http://lists.gnu.org/mailman/listinfo/gnustep-dev