Re: NSString bug with test and really dodgy patch.
On Oct 3, 2012, at 09:53, Richard Frith-Macdonald rich...@tiptree.demon.co.uk 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 abstract, the other C), 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: 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
