Re: NSString bug with test and really dodgy patch.

2012-10-03 Thread Jens Ayton
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

2011-07-06 Thread Jens Ayton
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

2011-06-16 Thread Jens Ayton
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

2011-02-17 Thread Jens Ayton
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....]

2011-01-01 Thread Jens Ayton
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....

2010-11-21 Thread Jens Ayton
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

2010-04-07 Thread Jens Ayton
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

2009-06-14 Thread Jens Ayton

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...)

2009-05-21 Thread Jens Ayton

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

2009-02-22 Thread Jens Ayton

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