Re: Linearly Scaling Text
> I hope that there are no issues scaling an NSTextView that is layer-backed > (either using NSView's scaleUnitSquareToSize method, or the bounds > manipulation approach that TextEdit uses). Unfortunately, there seems to be issues with scaling an NSTextView in a layer-backed hierarchy as well - I am encountering the same, somewhat garbled drawing of the editor, as mentioned in my previous posts. I'll file a radar with Apple. Any suggestions as to how to implement an editable text box in a zoomable, Core Animation layer-backed or layer-hosted hierarchy, would be much appreciated. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Intercepting click on send in Mail.app
Hi, Is it possible to intercept click on Send in Mac OS X Mail application? Thanks Nava Carmon ncar...@mac.com "Think good and it will be good!" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On Sun, 29 May 2011 18:15:10 -0400
>
> From: Jeffrey Walton wrote
> As Kyle said, its the C language - signed values are
> promoted/converted (?) to unsigned. So -1 is always greater than 1 (if
> you let it happen). Its really the generated CMP instruction which is
> bitting you. Cast the unsigned to an NSInteger (be mindful of overflow
> first).
>
> The compiler and/or clang should have warned you about it. A clean
> compile using -Wall -Wextra is not difficult with Cocoa/Cocoa Touch. I
> add the switches under "Other C Flags" (its easier than checking
> boxes). Also turn on clang. If you find you have a lot of interfaces
> and those interfaces have a lot of unused parameters, add
> -Wno-unused-parameter.
In replying to this email I take the opportunity also to reply to Siegfried,
Murat and Kyle.
I thank you all for your replies and advice especially regarding the use of
clang.
I would also like immediately to clarify that I have no problem accepting the
existence and usage of different numeric types. Moreover the moment I saw that
NSArray’s count method returned an NSUInteger I knew why my code wasn’t working
but that wasn’t my question. Let me repeat it.
Why did Cocoa developers make the count method return NSUInteger?
Both Murat and Kyle said this was because it does not make sense for an array
to have a negative number of elements. True but why because of that fact make
the output an NSUInteger?
In what contexts is that output going to be used?
I think that like me people will tend to use it in contexts to do with
accessing array elements
e.g. x = [ary objectAtIndex:[ary count]-2];
or modifying behaviour according to array size
e.g. if(k1 < ([ary count] - k2)) {…
I don’t often use the "if [array count]-x" formulation which is why I got into
trouble and why I’m asking the question.
If we know that a variable is never going to return a negative value and that
it is predominantly going to be used in an arithmetic context why force the
programmer to think about coercing the type on each occasion of its use when
failure to do so risks malfunction?
Moreover, as Jeffrey said, the cause of this programming error is subtle:
“Its really the generated CMP instruction which is bitting you.”.
Exactly.
NSInteger x = [ary count] - 3; delivers the unproblematic result
but if(x < ([ary count] - 3)) does not.
So was it really just because the number of array elements is never -3 that the
Cocoa developers decided to make NSArray count return type NSUInteger?
Julius
http://juliuspaintings.co.uk
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On 30 May 2011, at 12:03, julius wrote: > > > So was it really just because the number of array elements is never -3 that > the Cocoa developers decided to make NSArray count return type NSUInteger? > > Julius > You always need to pay close close attention to function/method return types, however we all get tripped up on such things from time to time. In this case, in addition to the illogicality of a negative index, the usage of NSUInteger as opposed to NSInteger doubles the available index range. Regards Jonathan Mitchell Developer Mugginsoft LLP http://www.mugginsoft.com___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
> In what contexts is that output going to be used?
> I think that like me people will tend to use it in contexts to do with
> accessing array elements
> e.g. x = [ary objectAtIndex:[ary count]-2];
well if you haven't already confirmed that [ary count ] can never be less than
2, or checked that [ ary count ] is larger than or equal to 2, or then you
shouldn't be trying to get the element at ( [ ary count ] - 2 ), you're going
to fail whatever the data type is, that's a logic error.
> or modifying behaviour according to array size
> e.g. if(k1 < ([ary count] - k2)) {…
again - if you don't already know that [ ary count ] >= k2, you should't
subtract k2 from it. if you don't know and want to do that statement with one
check use
If( ( k1 + k2 ) < [ ary count ] ) ..
> If we know that a variable is never going to return a negative value and that
> it is predominantly going to be used in an arithmetic context why force the
> programmer to think about coercing the type on each occasion of its use when
> failure to do so risks malfunction?
You don't need to coerce it. NSUInteger works perfectly well in an arithmetic
context. The programmer needs to ensure that they treat the data type within
its limits. You can't add 20,000,000 to an unsigned char and expect it to work,
similarly here you have to be aware of the kind of variable you have and treat
it appropriately. That If( ( k1 + k2 ) < [ ary count ] ) is a good example of
that.
>
> So was it really just because the number of array elements is never -3 that
> the Cocoa developers decided to make NSArray count return type NSUInteger?
Yes. Because NSArrays cannot have less than 0 elements, so there is no point at
all having the size of an array have a potential negative domain. It's
meaningless. They didn't use a double or a float for size either, because you
can't have 2.5 things in an array or look up the point at Array[ 23.4 ], well
not with this kind of array. They used the datatype which maps onto the thing
they are describing, array elements are non-negative integers, so they used
NSUInteger.
>
> Julius
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On 30/05/2011, at 9:03 PM, julius wrote: > Why did Cocoa developers make the count method return NSUInteger? Because you can't have negative numbers of elements in an array. It's that simple. The reason you're running into trouble is not because this type is unsigned, it's because you are doing arithmetic on it based on faulty assumptions. It's an error to assume that an index is valid just because you computed it to be so. It's always potentially buggy to do things like this: index = [array count] - 10; without checking whether what you end up with is in fact a valid index.You are not doing any such checking. The choice of an unsigned type by Cocoa engineers does not make this code suddenly wrong, it was always wrong. Accessing an array with an invalid index will throw an exception. Changing the index type to NSInteger wouldn't change that - the computed index is out of range whether it's expressed as a signed (negative) value or a large unsigned positive value. > If we know that a variable is never going to return a negative value and that > it is predominantly going to be used in an arithmetic context why force the > programmer to think about coercing the type on each occasion of its use when > failure to do so risks malfunction? It is not predominantly used in an arithmetic context, it's used to tell you the number of items in the array. You might use it to compute an offset into the array, but I would suggest that is pretty unusual. Coercing the type is not the right thing to do in any case - the type is what the type is (another advantage of using unsigned is that it effectively doubles the array's capacity, not that an array that large would ever be feasible). It's up to you to work with the types provided correctly, not complain that they made a bad design decision when in fact it's your code which is faulty. The onus is on you to ensure an array index is in range, or else be prepared for an exception. There's no way of twisting the arithmetic that lets you off doing this. > So was it really just because the number of array elements is never -3 that > the Cocoa developers decided to make NSArray count return type NSUInteger? Yes. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
An architectural question for iOS app
Hi all, I'm about to start writing an app (Target is iPad running 4.3 or later) but I've gotten to a position where I'm not sure of the best way to proceed with the architecture. I thought I'd better ask now before I paint myself into a corner. The parts of the app with which I am having trouble will be similar to a basic vector graphic or CAD program. The user will be able to add objects to the document/screen from a palette and then move these objects around and edit them in various ways. Most documents will have around 25 objects; 50 would be a large number. The objects will exist in a document level coordinate system which should be mapped to the view coordinate system. When the user does a pinch gesture, the objects will change in size but, at the end of the gesture, they should all be redrawn at the new size so that they look neat and so as to adjust the amount of details displayed within them. Finally, when the iPad is rotated I would like to keep graphical aspects of the document un-rotated but rotate the UI and any text on the document. So, given the above, I'm wondering how to represent the objects. Currently I just have them as subviews within the main view (which is a UIView within a UIScrollView) and I can drag them around (thanks to a gesture recogniser attached to each object's view) and I can pinch to zoom (thanks to the Scroll View). I haven't worked out how to do the level of detail stuff, though I read that CATiledLayer might be of assistance, but then I don't think that doesn't play well with the UIView-per-object architecture I currently have. The views seem to give me a fair bit of functionality - hit testing, animation, gesture recognition (of which I'll need more than the current drag around) - but I haven't worked out how to do the nice zoom-and-redraw stuff. Other issues I'm having (in the Simulator): Sometimes the scrolling of the scrollview doesn't happen and then randomly starts happening. Sometimes it starts happening even though I haven't zoomed; Sometimes it doesn't even though I have zoomed. There are no gesture recognisers on the larger views that might be interfering and I'm not accidentally touching the object views. I would have liked to use the transformation property of the main view to map the object view's coordinates to the UIViews coordinates. It seems like it should work but I've had no success with this and in my small proof-of-concept that I did I just resorted to direct manipulation of the coordinates. I haven't started with the rotation thing yet so I don't know if that will confuse me. Anyway, I would like comments/suggestions. Is the view-per-object approach reasonable and can you suggest solutions to my zooming-level-of-detail and other issues? Or should I do the whole thing in one view and do manual hit testing and dragging etc? Thanks, Brian.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Referencing struct fields in C
This question is related to C language, rather than Obj-C.
I have a data structure
typedef struct
{
int x;
int y;
} A;
In my code, I have a function foo(bool xOrY) that runs a long-lasting
loop that iterates through a huge array of A structures and for each
structure, it should get x or y field. The choice of x or y is the
same on each iteration, but may change between different calls of
foo(bool xOrY).
void foo(bool xOrY)
{
for(int i = 0; i < count; ++i)
{
if (xOrY)
{
int value = a[i].y;
...
}
else
{
int value = a[i].x;
...
}
}
}
I am looking to optimize this code, because the line if(xOrY) yields
the same result on each step. So I am thinking about this code:
void foo(bool xOrY)
{
struct A test;
size_t offset = 0;
if (xOrY)
{
offset = (char*)&(a.y) - (char*)&a;
}
else
{
offset = (char*)&(a.x) - (char*)&a;
}
for(int i = 0; i < count; ++i)
{
int value = *(int*)((char*)a + offset);
}
}
Is this approach valid at all? The compiler doesn't show any problem,
but I wonder if there can be any caveats related to structure aligning
etc.? It seems like it should not be a problem, because I am measuring
the offset in run time, but I am not quite sure...
I also thought about using a function pointer to switch between two
tiny functions, one of them returning x and the other y from a given
struct instance, but it seems somewhat more expensive than the above
approach (push/pop param from stack, call, return)
Thanks a lot!
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: An architectural question for iOS app
One Issue I'm having that I forgot to mention is that when I zoom in, the gesture recogniser on the objects ceases to recognise my attempts to drag and the scrollview drags instead - I have to zoom back out to near to 1:1 before I cant start dragging the objects again. On 30/05/2011, at 21:55 , Brian Bruinewoud wrote: > Hi all, > > I'm about to start writing an app (Target is iPad running 4.3 or later) but > I've gotten to a position where I'm not sure of the best way to proceed with > the architecture. I thought I'd better ask now before I paint myself into a > corner. > > The parts of the app with which I am having trouble will be similar to a > basic vector graphic or CAD program. The user will be able to add objects to > the document/screen from a palette and then move these objects around and > edit them in various ways. Most documents will have around 25 objects; 50 > would be a large number. The objects will exist in a document level > coordinate system which should be mapped to the view coordinate system. When > the user does a pinch gesture, the objects will change in size but, at the > end of the gesture, they should all be redrawn at the new size so that they > look neat and so as to adjust the amount of details displayed within them. > Finally, when the iPad is rotated I would like to keep graphical aspects of > the document un-rotated but rotate the UI and any text on the document. > > So, given the above, I'm wondering how to represent the objects. Currently I > just have them as subviews within the main view (which is a UIView within a > UIScrollView) and I can drag them around (thanks to a gesture recogniser > attached to each object's view) and I can pinch to zoom (thanks to the Scroll > View). I haven't worked out how to do the level of detail stuff, though I > read that CATiledLayer might be of assistance, but then I don't think that > doesn't play well with the UIView-per-object architecture I currently have. > The views seem to give me a fair bit of functionality - hit testing, > animation, gesture recognition (of which I'll need more than the current drag > around) - but I haven't worked out how to do the nice zoom-and-redraw stuff. > > Other issues I'm having (in the Simulator): > > Sometimes the scrolling of the scrollview doesn't happen and then randomly > starts happening. Sometimes it starts happening even though I haven't zoomed; > Sometimes it doesn't even though I have zoomed. There are no gesture > recognisers on the larger views that might be interfering and I'm not > accidentally touching the object views. > > I would have liked to use the transformation property of the main view to map > the object view's coordinates to the UIViews coordinates. It seems like it > should work but I've had no success with this and in my small > proof-of-concept that I did I just resorted to direct manipulation of the > coordinates. > > I haven't started with the rotation thing yet so I don't know if that will > confuse me. > > Anyway, I would like comments/suggestions. Is the view-per-object approach > reasonable and can you suggest solutions to my zooming-level-of-detail and > other issues? Or should I do the whole thing in one view and do manual hit > testing and dragging etc? > > Thanks, > Brian.___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/brian%40darknova.com > > This email sent to br...@darknova.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Referencing struct fields in C
oops, small correction, in the second code sample it should read:
if (xOrY)
{
offset = (char*)&(test.y) - (char*)&test;
}
else
{
offset = (char*)&(test.x) - (char*)&test;
}
On Mon, May 30, 2011 at 3:02 PM, Oleg Krupnov wrote:
> This question is related to C language, rather than Obj-C.
>
> I have a data structure
>
> typedef struct
> {
> int x;
> int y;
> } A;
>
> In my code, I have a function foo(bool xOrY) that runs a long-lasting
> loop that iterates through a huge array of A structures and for each
> structure, it should get x or y field. The choice of x or y is the
> same on each iteration, but may change between different calls of
> foo(bool xOrY).
>
> void foo(bool xOrY)
> {
> for(int i = 0; i < count; ++i)
> {
> if (xOrY)
> {
> int value = a[i].y;
> ...
> }
> else
> {
> int value = a[i].x;
> ...
> }
> }
> }
>
> I am looking to optimize this code, because the line if(xOrY) yields
> the same result on each step. So I am thinking about this code:
>
>
> void foo(bool xOrY)
> {
> struct A test;
> size_t offset = 0;
> if (xOrY)
> {
> offset = (char*)&(a.y) - (char*)&a;
> }
> else
> {
> offset = (char*)&(a.x) - (char*)&a;
> }
>
> for(int i = 0; i < count; ++i)
> {
> int value = *(int*)((char*)a + offset);
> }
> }
>
>
> Is this approach valid at all? The compiler doesn't show any problem,
> but I wonder if there can be any caveats related to structure aligning
> etc.? It seems like it should not be a problem, because I am measuring
> the offset in run time, but I am not quite sure...
>
> I also thought about using a function pointer to switch between two
> tiny functions, one of them returning x and the other y from a given
> struct instance, but it seems somewhat more expensive than the above
> approach (push/pop param from stack, call, return)
>
> Thanks a lot!
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Referencing struct fields in C
On 30/05/2011, at 10:10 PM, Oleg Krupnov wrote: >> I am looking to optimize this code Have you measured it and shown it to be a bottleneck, or are you just assuming it will benefit? --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Referencing struct fields in C
And no, I cannot move the for loop inside the if, because the
(omitted) code inside the for loop is huge, and I would hate to
duplicate it in the both if clauses...
Thanks Dmitry!
On Mon, May 30, 2011 at 3:12 PM, Dmitry Muraviev wrote:
> А почему вы не хотите перенести цикл внутрь условия?
>
>
>
> On 2011/May/30, at 16:02:09, Oleg Krupnov wrote:
>
>> This question is related to C language, rather than Obj-C.
>>
>> I have a data structure
>>
>> typedef struct
>> {
>> int x;
>> int y;
>> } A;
>>
>> In my code, I have a function foo(bool xOrY) that runs a long-lasting
>> loop that iterates through a huge array of A structures and for each
>> structure, it should get x or y field. The choice of x or y is the
>> same on each iteration, but may change between different calls of
>> foo(bool xOrY).
>>
>> void foo(bool xOrY)
>> {
>> for(int i = 0; i < count; ++i)
>> {
>> if (xOrY)
>> {
>> int value = a[i].y;
>> ...
>> }
>> else
>> {
>> int value = a[i].x;
>> ...
>> }
>> }
>> }
>>
>> I am looking to optimize this code, because the line if(xOrY) yields
>> the same result on each step. So I am thinking about this code:
>>
>>
>> void foo(bool xOrY)
>> {
>> struct A test;
>> size_t offset = 0;
>> if (xOrY)
>> {
>> offset = (char*)&(a.y) - (char*)&a;
>> }
>> else
>> {
>> offset = (char*)&(a.x) - (char*)&a;
>> }
>>
>> for(int i = 0; i < count; ++i)
>> {
>> int value = *(int*)((char*)a + offset);
>> }
>> }
>>
>>
>> Is this approach valid at all? The compiler doesn't show any problem,
>> but I wonder if there can be any caveats related to structure aligning
>> etc.? It seems like it should not be a problem, because I am measuring
>> the offset in run time, but I am not quite sure...
>>
>> I also thought about using a function pointer to switch between two
>> tiny functions, one of them returning x and the other y from a given
>> struct instance, but it seems somewhat more expensive than the above
>> approach (push/pop param from stack, call, return)
>>
>> Thanks a lot!
>> ___
>>
>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
>>
>> Please do not post admin requests or moderator comments to the list.
>> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
>>
>> Help/Unsubscribe/Update your Subscription:
>> http://lists.apple.com/mailman/options/cocoa-dev/muravievd%40gmail.com
>>
>> This email sent to muravi...@gmail.com
>
> Best regards,
>
> Dmitry Muraviev
> Software Engineer
> Vidau Systems
>
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Referencing struct fields in C
I knew this question was coming! :) Well, maybe you are right. The problem is that the function foo() involves much stuff, including disk I/O operations, so measuring its performance is quite tricky, you get different result on each test, depending on the available memory, disk busyness etc. It's hard to make a clean experiment. Generally, the foo() needs to be as fast as possible, because it is already long lasting. I have been optimizing foo() before, and now I need to make only a small change (choose x or y), and I am lazy to bother with profiling again, I just wanted to make the most optimal possible thing up front. Maybe it's just nit-picking... But I became curious if the above idea would be feasible at all! Thanks Graham! On Mon, May 30, 2011 at 3:16 PM, Graham Cox wrote: > > On 30/05/2011, at 10:10 PM, Oleg Krupnov wrote: > >>> I am looking to optimize this code > > > Have you measured it and shown it to be a bottleneck, or are you just > assuming it will benefit? > > --Graham > > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Referencing struct fields in C
On 30/05/2011, at 10:26 PM, Oleg Krupnov wrote: > I knew this question was coming! :) Well, maybe you are right. The > problem is that the function foo() involves much stuff, including disk > I/O operations, so measuring its performance is quite tricky, you get > different result on each test, depending on the available memory, disk > busyness etc. It's hard to make a clean experiment. Generally, the > foo() needs to be as fast as possible, because it is already long > lasting. I have been optimizing foo() before, and now I need to make > only a small change (choose x or y), and I am lazy to bother with > profiling again, I just wanted to make the most optimal possible thing > up front. Maybe it's just nit-picking... But I became curious if the > above idea would be feasible at all! This suggests that the optimisation you're contemplating is not going to be worthwhile. The tiny gains you might see due to eliminating one test-and-branch per loop are going to be swamped massively by these other things going on. It's not a case of not making a clean experiment, it's not going to be measurable*. In any case, the optimizer will probably move all of the loop-invariant state outside the loop for you, and it's likely to do a better job than your home-grown attempt. That said, I'm not sure how portable it is, but you could use offsetof() instead of pointer arithmetic, which is always a risky business. *Let's put some hypothetical numbers on this. Suppose your loop on its own, doing nothing else, takes 1mS. Your optimisation goes in and hey-presto, it takes 0.5mS. That looks great, a 100% improvement. Now add in all the "real world" code that has to be executed. It now takes 5 seconds. The 0.5mS you got is now a 0.01% improvement. QED. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
How to call delegate methods using YouTube embed technique?
What is the best way to call delegate methods using YouTube embed technique ? You can see two example on how to work with Youtube embed technique in these links : http://iphonedevelopertips.com/video/display-youtube-videos-without-exiting-your-application.html http://iphoneincubator.com/blog/windows-views/360idev-iphone-developers-conference-presentation Thanking you in advance. Willy Moral ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Referencing struct fields in C
> In any case, the optimizer will probably move all of the loop-invariant state
> outside the loop for you, and it's likely to do a better job than your
> home-grown attempt.
That's a great news! If it is really so, I stand corrected and not
trying to optimize it any further.
In fact, in the meantime I created a quick and dirty prototype to
measure this operation isolated, and it seems that out of 3 options
(plain if, function pointer, and pointer arithmetics) the plain if is
the winner, surprisingly :)
I also agree with what you said about negligibility of this
optimization compared to the rest of code. It's just sometimes hard to
stop nit-picking where you think you can optimize something, you know
:)
One thing that bothers me though. How the compiler will understand
that the state is loop-invariant? Should I necessarily declare the
checked boolean state as a local stack variable (unlike to a class
member variable that may change as a side-effect, if foo() was a class
method)?
for example
- (void)foo
{
bool xOrY = m_isXOrY;
for (int i = 0; i < N; ++i)
{
if (xOrY)
{
int value = a[i].y;
...
}
else
{
int value = a[i].y;
...
}
}
}
Would this suffice?
Thanks!
On Mon, May 30, 2011 at 4:14 PM, Graham Cox wrote:
>
> On 30/05/2011, at 10:26 PM, Oleg Krupnov wrote:
>
>> I knew this question was coming! :) Well, maybe you are right. The
>> problem is that the function foo() involves much stuff, including disk
>> I/O operations, so measuring its performance is quite tricky, you get
>> different result on each test, depending on the available memory, disk
>> busyness etc. It's hard to make a clean experiment. Generally, the
>> foo() needs to be as fast as possible, because it is already long
>> lasting. I have been optimizing foo() before, and now I need to make
>> only a small change (choose x or y), and I am lazy to bother with
>> profiling again, I just wanted to make the most optimal possible thing
>> up front. Maybe it's just nit-picking... But I became curious if the
>> above idea would be feasible at all!
>
>
> This suggests that the optimisation you're contemplating is not going to be
> worthwhile. The tiny gains you might see due to eliminating one
> test-and-branch per loop are going to be swamped massively by these other
> things going on. It's not a case of not making a clean experiment, it's not
> going to be measurable*. In any case, the optimizer will probably move all of
> the loop-invariant state outside the loop for you, and it's likely to do a
> better job than your home-grown attempt.
>
> That said, I'm not sure how portable it is, but you could use offsetof()
> instead of pointer arithmetic, which is always a risky business.
>
> *Let's put some hypothetical numbers on this. Suppose your loop on its own,
> doing nothing else, takes 1mS. Your optimisation goes in and hey-presto, it
> takes 0.5mS. That looks great, a 100% improvement. Now add in all the "real
> world" code that has to be executed. It now takes 5 seconds. The 0.5mS you
> got is now a 0.01% improvement. QED.
>
> --Graham
>
>
>
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
.. going back on list ..
On 30-May-2011, at 9:18 PM, julius wrote:
>
> On 30 May 2011, at 12:28, Roland King wrote:
>
>>
>>
>>> In what contexts is that output going to be used?
>>> I think that like me people will tend to use it in contexts to do with
>>> accessing array elements
>>> e.g. x = [ary objectAtIndex:[ary count]-2];
>>
>> well if you haven't already confirmed that [ary count ] can never be less
>> than 2, or checked that [ ary count ] is larger than or equal to 2, or then
>> you shouldn't be trying to get the element at ( [ ary count ] - 2 ), you're
>> going to fail whatever the data type is, that's a logic error.
> The intention of the example was to show a context.
> Of course it would be an error if I did not check blah.
If you check then there is no issue with that statement and it works perfectly
well.
>
>>
>>> or modifying behaviour according to array size
>>> e.g. if(k1 < ([ary count] - k2)) {…
>>
>> again - if you don't already know that [ ary count ] >= k2, you should't
>> subtract k2 from it. if you don't know and want to do that statement with
>> one check use
> ditto.
ditto
>>
>> If( ( k1 + k2 ) < [ ary count ] ) ..
> please do not rewrite my examples
> I said
> if(k1 < ([ary count] - k2)) {
> This is not about optimisation
> but the reason why the designers chose to have NSArray count return an
> NSUInteger.
Neither was my 'rewrite' about optimization. Again if you know that [ ary count
] >= k2 then your if() statement will work as-written.
>
>>
>>> If we know that a variable is never going to return a negative value and
>>> that it is predominantly going to be used in an arithmetic context why
>>> force the programmer to think about coercing the type on each occasion of
>>> its use when failure to do so risks malfunction?
>>
>> You don't need to coerce it.
> well in the piece of code which gave rise to all this I do, unless I rewrite
> using umpteen more lines of code.
No you don't. If you use NSUIntegers everywhere and check your bounds as you
say you do, you don't need to coerce anything to anything.
>
>> NSUInteger works perfectly well in an arithmetic context. The programmer
>> needs to ensure that they treat the data type within its limits. You can't
>> add 20,000,000 to an unsigned char and expect it to work, similarly here you
>> have to be aware of the kind of variable you have and treat it
>> appropriately. That If( ( k1 + k2 ) < [ ary count ] ) is a good example of
>> that.
> Precisely the point of my question.
> Why create a linguistic construct that has the potential to create problems
> if it skips one's mind that NSArray count returns NSUInteger as opposed to
> NSInteger which would not.
They didn't create a linguistic construct to do anything. They used a variable
correct for the type of the data they are representing. As a programmer you
need to think every time you subscript an array "am I going outside the bounds
of the array doing this", similarly when doing mathematical operations on
things which represent 'sizes of things which cannot be smaller than empty'.
>>
>>>
>>> So was it really just because the number of array elements is never -3 that
>>> the Cocoa developers decided to make NSArray count return type NSUInteger?
>>
>> Yes. Because NSArrays cannot have less than 0 elements, so there is no point
>> at all having the size of an array have a potential negative domain. It's
>> meaningless. They didn't use a double or a float for size either, because
>> you can't have 2.5 things in an array or look up the point at Array[ 23.4 ],
>> well not with this kind of array.
> Ok. This mixes two types of usage.
> In the case of if(k1 < ([ary count] - k2)) we are speaking about a return
> value which is used in a variety of contexts.
>
> In the case of ary[x] we are speaking about how we identify a particular
> array element and in C having a restriction on the type is used to enforce a
> useful rigour. Other languages might not do this because they have different
> objectives.
>
> In the if(k1 < ([ary count] - k2)) case I am asking why impose an NSUInteger
> complication when to do so has the potential to create problems precisely
> because in other contexts ([ary count] - k2) delivers the more intuitive
> result.
Again, as long as you have checked that [ ary count ] >= k2 before you do that
if(), you're fine. Or you rewrite it with +, as I did, it avoids the issue
because it recognizes that sizes can be added, but cannot be subtracted without
checking first, because there is no such thing as a negative size. size minus
bigger size is not a defined concept.
>
>> They used the datatype which maps onto the thing they are describing, array
>> elements are non-negative integers, so they used NSUInteger.
> So are you saying that the designers made this decision solely because of a
> particular interpretation of dogma?
No. I am saying that semantically the 'size' of an array
How to intercepting click on send in Mail.app
Hi, Is it possible to intercept click on Send in Mac OS X Mail application? I'm writing a client that on click on Send in Mail client should perform certain action Thanks ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa-dev Digest, Vol 8, Issue 383
On Mon, 30 May 2011 Roland King wrote
>
>
>> In what contexts is that output going to be used?
>> I think that like me people will tend to use it in contexts to do with
>> accessing array elements
>> e.g. x = [ary objectAtIndex:[ary count]-2];
>
> well if you haven't already confirmed that [ary count ] can never be less
> than 2, or checked that [ ary count ] is larger than or equal to 2, or then
> you shouldn't be trying to get the element at ( [ ary count ] - 2 ), you're
> going to fail whatever the data type is, that's a logic error.
The intention of the example was to show a context.
Of course it would be an error if I did not check blah.
>
>> or modifying behaviour according to array size
>> e.g. if(k1 < ([ary count] - k2)) {∑
>
> again - if you don't already know that [ ary count ] >= k2, you should't
> subtract k2 from it. if you don't know and want to do that statement with one
> check use
ditto.
>
> If( ( k1 + k2 ) < [ ary count ] ) ..
please do not rewrite my examples
I said
if(k1 < ([ary count] - k2)) {
This is not about optimisation
but the reason why the designers chose to have NSArray count return an
NSUInteger.
>
>> If we know that a variable is never going to return a negative value and
>> that it is predominantly going to be used in an arithmetic context why force
>> the programmer to think about coercing the type on each occasion of its use
>> when failure to do so risks malfunction?
>
> You don't need to coerce it.
well in the piece of code which gave rise to all this I do, unless I rewrite
using umpteen more lines of code.
> NSUInteger works perfectly well in an arithmetic context. The programmer
> needs to ensure that they treat the data type within its limits. You can't
> add 20,000,000 to an unsigned char and expect it to work, similarly here you
> have to be aware of the kind of variable you have and treat it appropriately.
> That If( ( k1 + k2 ) < [ ary count ] ) is a good example of that.
>
Precisely the point of my question.
Why create a linguistic construct that has the potential to create problems if
it skips one's mind that NSArray count returns NSUInteger as opposed to
NSInteger which would not.
>
>>
>> So was it really just because the number of array elements is never -3 that
>> the Cocoa developers decided to make NSArray count return type NSUInteger?
>
> Yes. Because NSArrays cannot have less than 0 elements, so there is no point
> at all having the size of an array have a potential negative domain. It's
> meaningless. They didn't use a double or a float for size either, because you
> can't have 2.5 things in an array or look up the point at Array[ 23.4 ], well
> not with this kind of array.
Ok. This mixes two types of usage.
In the case of if(k1 < ([ary count] - k2)) we are speaking about a return value
which is used in a variety of contexts.
In the case of ary[x] we are speaking about how we identify a particular array
element and in C having a restriction on the type is used to enforce a useful
rigour. Other languages might not do this because they have different
objectives.
In the if(k1 < ([ary count] - k2)) case I am asking why impose an NSUInteger
complication when to do so has the potential to create problems precisely
because in other contexts ([ary count] - k2) delivers the more intuitive result.
> They used the datatype which maps onto the thing they are describing, array
> elements are non-negative integers, so they used NSUInteger.
>
So are you saying that the designers made this decision solely because of a
particular interpretation of dogma?
Julius
http://juliuspaintings.co.uk
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to intercepting click on send in Mail.app
Le 30 mai 2011 à 15:02, Nava Carmon a écrit : > Is it possible to intercept click on Send in Mac OS X Mail application? > I'm writing a client that on click on Send in Mail client should perform > certain action Why not just get Mail Act-on from Indev http://www.indev.ca/MailActOn.html; it might save you reinventing the wheel :-) Joanna -- Joanna Carter Carter Consulting ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa-dev Digest, Vol 8, Issue 383
On 30 May 2011, Graham Cox wrote
>
> On 30/05/2011, at 9:03 PM, julius wrote:
>
>> Why did Cocoa developers make the count method return NSUInteger?
>
>
> Because you can't have negative numbers of elements in an array.
>
> It's that simple.
Yes but is that the only reason for doing this?
>
> The reason you're running into trouble is not because this type is unsigned,
> it's because you are doing arithmetic on it based on faulty assumptions. It's
> an error to assume that an index is valid just because you computed it to be
> so. It's always potentially buggy to do things like this:
>
> index = [array count] - 10;
>
> without checking whether what you end up with is in fact a valid index.You
> are not doing any such checking. The choice of an unsigned type by Cocoa
> engineers does not make this code suddenly wrong, it was always wrong.
> Accessing an array with an invalid index will throw an exception. Changing
> the index type to NSInteger wouldn't change that - the computed index is out
> of range whether it's expressed as a signed (negative) value or a large
> unsigned positive value.
Oh.. H.
Complicated and I'm not sure my discussing the preceding will not take us away
from why I asked the question.
Are you saying that the Cocoa engineers decided that NSArray count return
NSUInteger in order to deter people from using [ary count] as part of an
equation that accesses an element of an array? Or that they did so in order to
prevent people from using the length of an array in a decision making process?
I can't imagine that to be true.
>
>> If we know that a variable is never going to return a negative value and
>> that it is predominantly going to be used in an arithmetic context why force
>> the programmer to think about coercing the type on each occasion of its use
>> when failure to do so risks malfunction?
>
> It is not predominantly used in an arithmetic context, it's used to tell you
> the number of items in the array.
by arithmetic context I mean for instance [ary count]+1.
> You might use it to compute an offset into the array, but I would suggest
> that is pretty unusual. Coercing the type is not the right thing to do in
> any case - the type is what the type is
So let me get this right.
You are saying that I should write
NSInteger zIntVal = [ary count];
if(3 < (zIntVal - x)) {
or words to that effect
rather than
if(3 < ((NSInteger)[ary count] - x)) {
I'll think on it.
or are you saying I should not be using the length of an array in a computation?
But this is all taking us away from the question I asked.
> (another advantage of using unsigned is that it effectively doubles the
> array's capacity, not that an array that large would ever be feasible).
It is an answer but I can't accept it as being the main reason.
> It's up to you to work with the types provided correctly, not complain that
> they made a bad design decision when in fact it's your code which is faulty.
I am not complaining. I am asking about the reasons for a decision.
Of course I find decision to have NSArray count return NSUInteger somewhat
curious precisely because it seems to me liable to lead to subtle errors in
cases where programmers might have forgotten that NSArray count returns etc.
etc.
>
> The onus is on you to ensure an array index is in range, or else be prepared
> for an exception. There's no way of twisting the arithmetic that lets you off
> doing this.
If I have made any suggestions about twisting arithmetic then I am sincerely
sorry. I appear to have failed to express myself clearly and to have used
examples that offend.
>
>> So was it really just because the number of array elements is never -3 that
>> the Cocoa developers decided to make NSArray count return type NSUInteger?
>
> Yes.
Hmm. OK.
I don't think it is a sufficient reason.
I think the use of NSUInteger in this context is misguided.
My case essentially is
i. that it is a greater potential source of errors than not, e.g. my own
example.
ii. that it unnecessarily increases program complexity. This happens every time
a data type or command is added to a language. I think that we should never
increase the complexity of our programming tools beyond the minimum necessary.
This does not mean we should not use NSUInteger simply that our use of it
should be judicious and in places where it might be expected and not where it
might cause difficulties. Secondly we do not expect c arrays to have negative
length thus using NSUInteger is unnecessary. It does not inform and does not
provide protection against error since the array length will never be negative.
Thus it fulfils no practical purpose - or does it? That is what I would like to
know.
Julius
http://juliuspaintings.co.uk
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moder
Re: Why does NSArray count return NSUInteger?
On 30 May 2011, Graham Cox wrote
>
> On 30/05/2011, at 9:03 PM, julius wrote:
>
>> Why did Cocoa developers make the count method return NSUInteger?
>
>
> Because you can't have negative numbers of elements in an array.
>
> It's that simple.
Yes but is that the only reason for doing this?
>
> The reason you're running into trouble is not because this type is unsigned,
> it's because you are doing arithmetic on it based on faulty assumptions. It's
> an error to assume that an index is valid just because you computed it to be
> so. It's always potentially buggy to do things like this:
>
> index = [array count] - 10;
>
> without checking whether what you end up with is in fact a valid index.You
> are not doing any such checking. The choice of an unsigned type by Cocoa
> engineers does not make this code suddenly wrong, it was always wrong.
> Accessing an array with an invalid index will throw an exception. Changing
> the index type to NSInteger wouldn't change that - the computed index is out
> of range whether it's expressed as a signed (negative) value or a large
> unsigned positive value.
Oh.. H.
Complicated and I'm not sure my discussing the preceding will not take us away
from why I asked the question.
Are you saying that the Cocoa engineers decided that NSArray count return
NSUInteger in order to deter people from using [ary count] as part of an
equation that accesses an element of an array? Or that they did so in order to
prevent people from using the length of an array in a decision making process?
I can't imagine that to be true.
>
>> If we know that a variable is never going to return a negative value and
>> that it is predominantly going to be used in an arithmetic context why force
>> the programmer to think about coercing the type on each occasion of its use
>> when failure to do so risks malfunction?
>
> It is not predominantly used in an arithmetic context, it's used to tell you
> the number of items in the array.
by arithmetic context I mean for instance [ary count]+1.
>
> You might use it to compute an offset into the array, but I would suggest
> that is pretty unusual. Coercing the type is not the right thing to do in
> any case - the type is what the type is
So let me get this right.
You are saying that I should write
NSInteger zIntVal = [ary count];
if(3 < (zIntVal - x)) {
or words to that effect
rather than
if(3 < ((NSInteger)[ary count] - x)) {
I'll think on it.
or are you saying I should not be using the length of an array in a computation?
But this is all taking us away from the question I asked.
> (another advantage of using unsigned is that it effectively doubles the
> array's capacity, not that an array that large would ever be feasible).
It is an answer but I can't accept it as being the main reason.
> It's up to you to work with the types provided correctly, not complain that
> they made a bad design decision when in fact it's your code which is faulty.
I am not complaining. I am asking about the reasons for a decision.
Of course I find decision to have NSArray count return NSUInteger somewhat
curious precisely because it seems to me liable to lead to subtle errors in
cases where programmers might have forgotten that NSArray count returns etc.
etc.
>
> The onus is on you to ensure an array index is in range, or else be prepared
> for an exception. There's no way of twisting the arithmetic that lets you off
> doing this.
If I have made any suggestions about twisting arithmetic then I am sincerely
sorry. I appear to have failed to express myself clearly and to have used
examples that offend.
>
>> So was it really just because the number of array elements is never -3 that
>> the Cocoa developers decided to make NSArray count return type NSUInteger?
>
> Yes.
Hmm. OK.
I don't think it is a sufficient reason.
I think the use of NSUInteger in this context is misguided.
My case essentially is
i. that it is a greater potential source of errors than not, e.g. my own
example.
ii. that it unnecessarily increases program complexity. This happens every time
a data type or command is added to a language. I think that we should never
increase the complexity of our programming tools beyond the minimum necessary.
This does not mean we should not use NSUInteger simply that our use of it
should be judicious and in places where it might be expected and not where it
might cause difficulties. Secondly we do not expect c arrays to have negative
length thus using NSUInteger is unnecessary. It does not inform and does not
provide protection against error since the array length will never be negative.
Thus it fulfils no practical purpose - or does it? That is what I would like to
know.
Julius
http://juliuspaintings.co.uk
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact th
Re: How to intercepting click on send in Mail.app
Actually the client is supposed to get a text from the mail message when the user clicks send. This client is not a mail client and not is supposed to send mail. Is there some programmatic solution? Thanks On May 30, 2011, at 5:12 PM, Joanna Carter wrote: > Le 30 mai 2011 à 15:02, Nava Carmon a écrit : > >> Is it possible to intercept click on Send in Mac OS X Mail application? >> I'm writing a client that on click on Send in Mail client should perform >> certain action > > Why not just get Mail Act-on from Indev http://www.indev.ca/MailActOn.html; > it might save you reinventing the wheel :-) > > Joanna > > -- > Joanna Carter > Carter Consulting > Nava Carmon ncar...@mac.com "Think good and it will be good!" ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Cocoa-dev Digest, Vol 8, Issue 383
On 31/05/2011, at 12:03 AM, julius wrote: > has the potential to create problems if it skips one's mind Well, so does almost anything in life. Coding's no different. > Of course I find decision to have NSArray count return NSUInteger somewhat > curious precisely because it seems to me liable to lead to subtle errors in > cases where programmers might have forgotten that NSArray count returns etc. > etc. Designers can't be expected to anticipate and compensate for your bad memory. The documentation states clearly what's what. It's up to you to take that on board. "Forgetting" is not a good reason to design something differently. > Are you saying that the Cocoa engineers decided that NSArray count return > NSUInteger in order to deter people from using [ary count] as part of an > equation that accesses an element of an array? Or that they did so in order > to prevent people from using the length of an array in a decision making > process? > I can't imagine that to be true. I'm not saying that at all. Doing index arithmetic with unsigned values is perfectly straightforward if you need to do it. There's no 'deterrence' in having the type unsigned, it's the correct and logical way to represent a positive index. Making it signed does not, despite what you think, make the arithmetic any easier, nor harder, nor does it lead to less coding effort. You just have to know what you're dealing with. > You are saying that I should write > NSInteger zIntVal = [ary count]; Nope. I'm saying you should write: NSUInteger zIntVal = [ary count]; ...and write the rest of your code correctly. I'm not actually sure what you're trying to do with it. > I think the use of NSUInteger in this context is misguided. So file bugs against it. Good luck with that. I doubt you'll get much support from many programmers on this list however. > This does not mean we should not use NSUInteger simply that our use of it > should be judicious and in places where it might be expected and not where it > might cause difficulties. I would say that its use as an index in NSArray is a perfect example of using it judiciously, in a place where it would be expected, and where it does not cause difficulties (for most of us anyway). --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Referencing struct fields in C
On 30/05/2011, at 11:30 PM, Oleg Krupnov wrote: > In fact, in the meantime I created a quick and dirty prototype to > measure this operation isolated, and it seems that out of 3 options > (plain if, function pointer, and pointer arithmetics) the plain if is > the winner, surprisingly :) Not that surprising. Modern CPUs are highly pipelined, and a conditional like that won't slow things if it's repeatedly coming up with the same answer. > One thing that bothers me though. How the compiler will understand > that the state is loop-invariant? Should I necessarily declare the > checked boolean state as a local stack variable (unlike to a class > member variable that may change as a side-effect, if foo() was a class > method)? No, just leave it. It can see that it's loop-invariant because it's passed in as a value to the function - within the function nothing ever changes its value. Copying it to another variable might do more harm than good (though I suspect the optimizer wouldn't be fazed by that). Another way to "optimise" in a simple manner is just to have two loops, one for true and one for false. Effectively that's how the optimizer rewrites your code anyway. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On May 30, 2011, at 7:31 AM, Roland King wrote: > No. I am saying that semantically the 'size' of an array is a non-negative > integer and thus the correct way to represent it is with a data type which > represents non-negative integers. While that is certainly correct, the counter argument is that it is widely considered "good hygiene" in C to only use unsigned ints where you really need unsigned, because of the high potential for "hilarity" if one ever forgets and makes a simple subtraction where one shouldn't. It's really not worth the picky semantic correctness to use a type which can so easily cause so many bugs. -- Scott Ribe scott_r...@elevated-dev.com http://www.elevated-dev.com/ (303) 722-0567 voice ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Problem using data in a distributed object
HI I wrote two apps that communicate through distributed objects and found this weird "feature" where if a string is distributed by one app, the receiving app can't use it to create other strings. For example str1 is vended from app A App B wants to take that string and append some text to the end, like so NSString*newString = [vendedString stringByAppendingString: @"testing 1, 2, 3"]; Not sure why, but once the execution reaches that step, the program just stops dead in it's tracks. It doesn't crash, but just seems to get hung on that line, never executing anything beyond it. Is there a way to actually use data vended by a distributed object other than to passively read it? If so, how? Thanks for any help___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Referencing struct fields in C
> From: Oleg Krupnov
> Date: May 30, 2011 9:30:22 AM EDT
> To: Graham Cox
> Cc: Cocoa-Dev List
> Subject: Re: Referencing struct fields in C
<>
> One thing that bothers me though. How the compiler will understand
> that the state is loop-invariant? Should I necessarily declare the
> checked boolean state as a local stack variable (unlike to a class
> member variable that may change as a side-effect, if foo() was a class
> method)?
>
> for example
> - (void)foo
> {
> bool xOrY = m_isXOrY;
> for (int i = 0; i < N; ++i)
> {
> if (xOrY)
> {
> int value = a[i].y;
> ...
> }
> else
> {
> int value = a[i].y;
> ...
> }
> }
> }
>
> Would this suffice?
>
> Thanks!
Oleg, have you tried looking at the assembly output from the compiler? It
might be doing something stranger than that. One possibility is that it
coalesces all code into two chunks, one for when xOrY is true, and the other
when its false, in which case there is exactly one branch being evaluated.
That said, if you're really trying to tweak your performance, you're probably
better off looking into -fprofile-generate and -fprofile-use (in gcc) than what
you're suggesting. Hand tweaking WITHOUT adequate profiling as you're
suggesting is the absolute bane of programming; you'll be spending a lot of
time 'optimizing' without really knowing if you're improving things or not...
Thanks,
Cem Karan___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On 30 May 2011, at 16:02, Graham Cox wrote: > > On 31/05/2011, at 12:03 AM, julius wrote: > >> has the potential to create problems if it skips one's mind > > Well, so does almost anything in life. Coding's no different. > >> Of course I find decision to have NSArray count return NSUInteger somewhat >> curious precisely because it seems to me liable to lead to subtle errors in >> cases where programmers might have forgotten that NSArray count returns etc. >> etc. > > Designers can't be expected to anticipate and compensate for your bad memory. Well actually I disagree. I think human factors are very important especially in situations where the tools in question need to facilitate clear expression of complex problems and reduce the risk of untoward errors. > The documentation states clearly what's what. It's up to you to take that on > board. "Forgetting" is not a good reason to design something differently. Yes but again human factors come into play. > > > ...and write the rest of your code correctly. I'm not actually sure what > you're trying to do with it. What I am trying to do with my code is irrelevant to the question I asked as is also the issue of whether or not I write good code. > >> I think the use of NSUInteger in this context is misguided. > > So file bugs against it. Good luck with that. I doubt you'll get much support > from many programmers on this list however. No. I am not going to do that. All I had hoped was that someone on this list might illuminate the issue more than has happened so far. Julius http://juliuspaintings.co.uk ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Aquatic Prime
See the updated Aquatic Prime at: https://github.com/bdrister/AquaticPrime Best regards, John MacMullin Email:john.macmul...@cox.net Skype: john_macmullin www.macmullin.info ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On 30-May-2011, at 11:05 PM, julius wrote: > > On 30 May 2011, at 15:52, Roland King wrote >> >> On 30-May-2011, at 9:18 PM, julius wrote: >> >>> They used the datatype which maps onto the thing they are describing, array elements are non-negative integers, so they used NSUInteger. >>> So are you saying that the designers made this decision solely because of a >>> particular interpretation of dogma? >> >> No. I am saying that semantically the 'size' of an array is a non-negative >> integer and thus the correct way to represent it is with a data type which >> represents non-negative integers. > > If that were all there was to it then I might agree but I don't think it is. > I think issues of program language complexity and the propensity of language > constructs to induce coding errors are more important. > > Julius > Whist seeing your side, I respectfully disagree. I think data types should as closely as possible align with the data they actually represent. Perhaps the best solution would be an object data type for size of an array which had syntax which stopped anyone misusing it, methods for iteration, for comparison etc. which left no way to make an error (I think that's called C++ :) ). I'm personally very happy with unsigned integer for size of/index into array and when I see 'unsigned' on a type I'm reminded what comparisons are valid on the zero side; I will admit to having blown myself up on more than one occasion overflowing a type on the high side, I've rarely messed up subtracting unsigned types without considering whether the subtraction is valid, but I'm sure there was a time years ago I learned that lesson and probably the hard way. I still think that if you do reasonable checks on array sizes before you use them, most comparisons are valid for sizes without issue and those checks always seem to me to be part of the logic you should be writing anyway to differentiate cases. I like NSUInteger because it reminds me what type of data I'm really dealing with. If Cocoa used NSInteger I'm sure I'd have gotten used to that as well, and I'm sure I'd have found a few cases in which I'd wondered why they didn't do it the unsigned way. > > > http://juliuspaintings.co.uk > > > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
How to extract files from zip archive?
Hi All!
I need to extract zip-archive content to ~/Library/Application
Support/My Program/Shared at the first launch.
What the best way to do it?
I tried to
NSString * listsPath = STR_ADDPATH([[NSBundle mainBundle]
resourcePath], @"lists.zip");
if (0 == folderSize &&
FileTools::DoesFileExist(filesystem_rep(listsPath)))
{
NSTask * task = [[NSTask alloc] init];
[task setLaunchPath:@"/usr/bin/unzip"];
NSArray * args = [NSArray arrayWithObjects:@"-a ", listsPath, @" -d
", sharedPath, nil];
[task setArguments: args];
[task launch];
[task waitUntilExit];
int status = [task terminationStatus];
[task release];
if (status)
{
NSLog(@"Failed to unpack lists to %@", sharedPath);
}
}
but status is 10, I guess because spaces are in the path.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: How to intercepting click on send in Mail.app
Le 30 mai 2011 à 15:51, Nava Carmon a écrit : > Actually the client is supposed to get a text from the mail message when the > user clicks send. This client is not a mail client and not is supposed to > send mail. > Is there some programmatic solution? Mail Act-On can call Apple Script, which can do whatever you want with scriptable applications. I have a script that reacts to a message being sent and creates a To-Do item in Things. Joanna -- Joanna Carter Carter Consulting ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to extract files from zip archive?
>NSArray * args = [NSArray arrayWithObjects:@"-a ", listsPath, @" -d
", sharedPath, nil];
Why do you have spaces in your args? It's not going to concatenate them into a
single command line string, it's going to pass them in as the separate args to
the app's "main".
- Original Message -
From: "Vyacheslav Karamov"
To: Cocoa-dev@lists.apple.com
Sent: Monday, May 30, 2011 8:45:51 AM
Subject: How to extract files from zip archive?
Hi All!
I need to extract zip-archive content to ~/Library/Application
Support/My Program/Shared at the first launch.
What the best way to do it?
I tried to
NSString * listsPath = STR_ADDPATH([[NSBundle mainBundle]
resourcePath], @"lists.zip");
if (0 == folderSize &&
FileTools::DoesFileExist(filesystem_rep(listsPath)))
{
NSTask * task = [[NSTask alloc] init];
[task setLaunchPath:@"/usr/bin/unzip"];
NSArray * args = [NSArray arrayWithObjects:@"-a ", listsPath, @" -d
", sharedPath, nil];
[task setArguments: args];
[task launch];
[task waitUntilExit];
int status = [task terminationStatus];
[task release];
if (status)
{
NSLog(@"Failed to unpack lists to %@", sharedPath);
}
}
but status is 10, I guess because spaces are in the path.
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/lrucker%40vmware.com
This email sent to lruc...@vmware.com
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Linearly Scaling Text
My view isn't even zoomable, but if the text in the textview doesn't completely fit in the box, when I go to edit it goes from a perfectly legible "long string with ..." to a very fuzzy "long string with truncation". I'm half-tempted to just make it non-editable. - Original Message - From: "Ajay Sabhaney" To: "Kyle Sluder" Cc: "cocoa-dev List" Sent: Monday, May 30, 2011 1:21:31 AM Subject: Re: Linearly Scaling Text > I hope that there are no issues scaling an NSTextView that is layer-backed > (either using NSView's scaleUnitSquareToSize method, or the bounds > manipulation approach that TextEdit uses). Unfortunately, there seems to be issues with scaling an NSTextView in a layer-backed hierarchy as well - I am encountering the same, somewhat garbled drawing of the editor, as mentioned in my previous posts. I'll file a radar with Apple. Any suggestions as to how to implement an editable text box in a zoomable, Core Animation layer-backed or layer-hosted hierarchy, would be much appreciated. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/lrucker%40vmware.com This email sent to lruc...@vmware.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem using data in a distributed object
On May 30, 2011, at 10:20 AM, Ken Tozier wrote: > I wrote two apps that communicate through distributed objects and found this > weird "feature" where if a string is distributed by one app, the receiving > app can't use it to create other strings. For example > > str1 is vended from app A > App B wants to take that string and append some text to the end, like so > > NSString *newString = [vendedString stringByAppendingString: > @"testing 1, 2, 3"]; > > Not sure why, but once the execution reaches that step, the program just > stops dead in it's tracks. It doesn't crash, but just seems to get hung on > that line, never executing anything beyond it. Is there a way to actually use > data vended by a distributed object other than to passively read it? If so, > how? I'm guessing that whatever method vended the string didn't do so with the bycopy qualifier. Therefore, you have a proxy of the string object and any messages you send it require communication with the server. The deadlock is probably because of a problem in the design of the communication between the server and your client -- you are asking the server to process your request, but maybe the server is blocked trying to send the client a message. When you hit a deadlock, you can interrupt/pause the programs in the debugger and examine the backtraces of their threads. You'll probably see why they are deadlocked, because each is doing something that requires a response from the other before it can proceed. Getting the string bycopy may be sufficient to solve this deadlock. However, you should carefully reexamine the design of the interaction between the client and server. Good luck, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Problem using data in a distributed object
On May 30, 2011, at 12:08 PM, kentoz...@comcast.net wrote: > Thanks Ken You're welcome. > How do I specify "by copy" when sending? > > For example, say object A sends data to B like so: > > [objectB performSelector: @selector(handleRequest:) withObject: vendedObject]; I'm not sure what you're getting at here. The mention of vendedObject suggests that you're thinking of bycopy in the wrong way, that you're thinking it's a way of treating an object after you've already received it via D.O. Rather, bycopy describes what you receive via D.O. Your earlier case involved a string, and strings are almost always value objects suitable for copying, rather than sharing. That is, it doesn't make much sense to share an immutable string between the client and server, and it would be hideous to share a mutable string where you wanted changes done by either to be visible to both. Therefore, you'd use something like the following to obtain a string: - (bycopy NSString*) getSomeString; In the client: NSString* aString = [serverRootProxy getSomeString]; After that, aString is independent from the server. If that's not what you were asking, then I'm not sure if you can specify bycopy with a -performSelect:... method. I don't know how D.O. handles -performSelector:withObject:. I don't know if it encodes that method or if it encodes the method to be performed (here -handleRequest:). Why are you doing it this way? Why not: [objectB handleRequest:vendedObject] ? In that case, you'd declare -handleRequest: with the bycopy qualifier on its argument. Although, again, having just written the above code snippet, it's very peculiar that you already have a vended object and _now_ you're worrying about how to pass it by-copy to -handleRequest:. That's the wrong way to think about it. Regards, Ken ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On May 30, 2011, at 08:27, julius wrote: > All I had hoped was that someone on this list might illuminate the issue more > than has happened so far. The problem isn't really lack of illumination, but that you're not prepared to accept the consequences of the explanation. Here's my version of the illumination: The designers of the Cocoa APIs -- in common with designers a lot of other APIs -- have followed a general design principle, which is to use the parameter/return type that most accurately describes the data being passed. The purposes of this, presumably, include: -- It's self documenting to a degree. -- It at least theoretically provides opportunities for compile-type (== better) error messages if you accidentally pass a value of the wrong type. -- It at least theoretically eliminates the need to code some range validation checks. along with other reasons I can't think of right now. None of those reasons is perfect. That's in part because the C language isn't strict enough for the purpose (e.g. it's very lax in distinguishing between enum and int values), and in part because Cocoa APIs have come to make some compromises (e.g. for 32/64 transition reasons, Cocoa mostly doesn't use enums any more), or have set in stone some inconsistencies (row indexes in NSTableView being NSInteger, with -1 meaning an invalid index vs. element indexes in NSArray being NSUInteger, with NSNotFound meaning an invalid index). That, or something like it, *is* the reason. But you won't accept it, because that isn't really the issue that's put a bee in your bonnet. What you've *really* been arguing is nothing to do with Cocoa at all. You've been arguing that in C (and C-based languages like Objective-C), it's unconscionable to make routine use of unsigned variable types, because it imposes a burden on the programmer to code -- specifically to write arithmetic expressions and comparisons -- in different styles depending on the types of the variables involved. Yes, it's a burden, in the sense that you do need to know the type of the variables involved, and you do need to write code with that knowledge in mind: if (signedVariable - 10 > 3) ... if (unsignedVariable > 10 + 3) ... The only solution to that would be to remove unsigned types from the language***. Perhaps you could even make a compelling argument for doing that. (After all, countless hours *have* been lost debugging problems arising from mixing signed and unsigned variables in source code.) By all means go out on the C streets and fight that battle, but blaming Cocoa for this seems like a waste of everyone's time. ***Well, what you've actually being arguing is that we should all agree to pretend that they're not in the language.___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
A couple of other issues about the use of NSUInteger throughout the Foundation Framework. Core Foundation functions tend to use CFIndex and CFRange, both signed. This is true for CFArray and other collections. If you mix Foundation and Core Foundation you have to deal with this. Many C functions also use int. The use of NSUInteger seems to be an exception to common C usage. I am not saying it is wrong but it is at odds with other conventions. It would be interesting to find out why NSUInteger was chosen. Bruce Turner bmtur...@optonline.net ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Referencing struct fields in C
What cured me of optimization-itis was this entry in ridiculousfish's ridiculously cool blog: http://ridiculousfish.com/blog/archives/2010/07/23/will-it-optimize/#fish_made_a_mess --Rob >> One thing that bothers me though. How the compiler will understand >> that the state is loop-invariant? Should I necessarily declare the >> checked boolean state as a local stack variable (unlike to a class >> member variable that may change as a side-effect, if foo() was a class >> method)? > > No, just leave it. It can see that it's loop-invariant because it's passed in > as a value to the function - within the function nothing ever changes its > value. Copying it to another variable might do more harm than good (though I > suspect the optimizer wouldn't be fazed by that). > > Another way to "optimise" in a simple manner is just to have two loops, one > for true and one for false. Effectively that's how the optimizer rewrites > your code anyway. > > --Graham > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On 31/05/2011, at 12:03 AM, julius wrote: > has the potential to create problems if it skips one's mind On 05/30/2011 8:40 AM, "Roland King" wrote: > Whist seeing your side... You know, we could really take this to the extreme and I could get upset that Roland started talking about a card game on a Cocoa e-mail list, or I could just realize he's probably British and misspelled "whilst". In that case, I could get really upset he's using British English on an e-mail list of a company located in America, or I could just realize he's using a different spelling more common to his locale and move on to more important things. Fixing a buggy index calculation takes less time and is more productive in getting one's mind straight than it does arguing why Apple (and compiler developers, if we take this to the extreme) should do something different. If this is truly upsetting, go write a bug. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Re: Linearly Scaling Text
When I implemented a scalable teleprompter screen in MacOS, I did it by rendering the text in a narrow view that was scaled down by the scale factor, then scaled the view up to fill the containing view. With a little work, it was fully editable. I was not using CALayers at the time. When I tried to do the same on iOS, in which every view is layer backed, the layer scaled with the view and resulted in blocky text, definitely not what I wanted. Because it was mono-Font text, I resorted to scaling the font instead. Later, because of view size limitations on layer-backed views in iOS, I implemented a tiled view. I never went back to view scaling, but I wonder if you could control the granularity of the involved CALayers such that a tiled view would produce a clean result when scaled up? Just a thought. On 5/30/11 12:30 PM, "cocoa-dev-requ...@lists.apple.com" wrote: > > My view isn't even zoomable, but if the text in the textview doesn't > completely fit in the box, when I go to edit it goes from a perfectly legible > "long string with ..." to a very fuzzy "long string with truncation". I'm > half-tempted to just make it non-editable. > > - Original Message - > From: "Ajay Sabhaney" > To: "Kyle Sluder" > Cc: "cocoa-dev List" > Sent: Monday, May 30, 2011 1:21:31 AM > Subject: Re: Linearly Scaling Text > >> > I hope that there are no issues scaling an NSTextView that is layer-backed >> (either using NSView's scaleUnitSquareToSize method, or the bounds >> manipulation approach that TextEdit uses). > > Unfortunately, there seems to be issues with scaling an NSTextView in a > layer-backed hierarchy as well - I am encountering the same, somewhat garbled > drawing of the editor, as mentioned in my previous posts. I'll file a radar > with Apple. > > Any suggestions as to how to implement an editable text box in a zoomable, > Core Animation layer-backed or layer-hosted hierarchy, would be much > appreciated. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On 30 May 2011, at 16:40, Roland King wrote: > > On 30-May-2011, at 11:05 PM, julius wrote: > >> >> On 30 May 2011, at 15:52, Roland King wrote >>> >>> On 30-May-2011, at 9:18 PM, julius wrote: >>> > They used the datatype which maps onto the thing they are describing, > array elements are non-negative integers, so they used NSUInteger. So are you saying that the designers made this decision solely because of a particular interpretation of dogma? >>> >>> No. I am saying that semantically the 'size' of an array is a non-negative >>> integer and thus the correct way to represent it is with a data type which >>> represents non-negative integers. >> >> If that were all there was to it then I might agree but I don't think it is. >> I think issues of program language complexity and the propensity of language >> constructs to induce coding errors are more important. >> >> Julius >> > > Whist seeing your side, I respectfully disagree. I think data types should as > closely as possible align with the data they actually represent. But why do you think this requirement should trump all others and in all cases? Julius http://juliuspaintings.co.uk ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On 30 May 2011, at 20:03,Quincey Morris wrote > > On May 30, 2011, at 08:27, julius wrote: > >> All I had hoped was that someone on this list might illuminate the issue >> more than has happened so far. > > The problem isn't really lack of illumination, but that you're not prepared > to accept the consequences of the explanation. Hilarity and riot. > > Here's my version of the illumination: > snip > -- It at least theoretically provides opportunities for compile-type (== > better) error messages if you accidentally pass a value of the wrong type. > > -- It at least theoretically eliminates the need to code some range > validation checks. > Here is a nice instance that I think quite germane. The input parameter to NSArray's objectAtIndex: is an NSUInteger. Both these code snippets work perfectly (they retrieve element 3). zStr = [zAry objectAtIndex:3.1]; and CGFloat zF1 = 3.2; zStr = [zAry objectAtIndex:zF1]; I'm sure that by setting the right flags one could get warning messages to appear. Julius http://juliuspaintings.co.uk ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On May 30, 2011, at 1:45 PM, julius wrote:
>
> On 30 May 2011, at 20:03,Quincey Morris wrote
>>
>> On May 30, 2011, at 08:27, julius wrote:
>>
>>> All I had hoped was that someone on this list might illuminate the issue
>>> more than has happened so far.
>>
>> The problem isn't really lack of illumination, but that you're not prepared
>> to accept the consequences of the explanation.
>
> Hilarity and riot.
>
>>
>> Here's my version of the illumination:
>>
> snip
>> -- It at least theoretically provides opportunities for compile-type (==
>> better) error messages if you accidentally pass a value of the wrong type.
>>
>> -- It at least theoretically eliminates the need to code some range
>> validation checks.
>>
>
> Here is a nice instance that I think quite germane.
>
> The input parameter to NSArray's objectAtIndex: is an NSUInteger.
> Both these code snippets work perfectly (they retrieve element 3).
> zStr = [zAry objectAtIndex:3.1];
> and
> CGFloat zF1 = 3.2;
> zStr = [zAry objectAtIndex:zF1];
>
> I'm sure that by setting the right flags one could get warning messages to
> appear.
Julius,
As others have pointed out, this has nothing to do with Objective-C or Cocoa.
This behavior is true of any C derived language or library. If this aspect of C
bothers you, then please consider adding -Wconversion to your project's build
settings (CFLAGS):
$ clang -Wall -Wextra -Wconversion -Os -c test.c
test.c:2:18: warning: implicit conversion turns literal floating-point number
into integer: 'double' to 'unsigned int'
[-Wliteral-conversion]
void g(void) { f(3.1); f(-1); }
~ ^~~
test.c:2:26: warning: implicit conversion changes signedness: 'int' to
'unsigned int' [-Wsign-conversion]
void g(void) { f(3.1); f(-1); }
~ ^~
2 warnings generated.
$
davez
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On Mon, 30 May 2011 13:56:38 -0700, Dave Zarzycki said:
>As others have pointed out, this has nothing to do with Objective-C or
>Cocoa. This behavior is true of any C derived language or library. If
>this aspect of C bothers you, then please consider adding -Wconversion
>to your project's build settings (CFLAGS):
>
>$ clang -Wall -Wextra -Wconversion -Os -c test.c
>test.c:2:18: warning: implicit conversion turns literal floating-point
>number into integer: 'double' to 'unsigned int'
> [-Wliteral-conversion]
>void g(void) { f(3.1); f(-1); }
> ~ ^~~
>test.c:2:26: warning: implicit conversion changes signedness: 'int' to
>'unsigned int' [-Wsign-conversion]
>void g(void) { f(3.1); f(-1); }
> ~ ^~
Though one should only use -Wconversion with clang, and not the Apple-
provided gcc 4.2, where it has a different meaning and is largely
useless (fixed in newer gcc).
--
Sean McBride, B. Eng s...@rogue-research.com
Rogue Researchwww.rogue-research.com
Mac Software Developer Montréal, Québec, Canada
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On 30 May 2011, at 21:56, Dave Zarzycki wrote: > On May 30, 2011, at 1:45 PM, julius wrote: > >> >> On 30 May 2011, at 20:03,Quincey Morris wrote >>> >>> On May 30, 2011, at 08:27, julius wrote: >>> All I had hoped was that someone on this list might illuminate the issue more than has happened so far. >>> >>> The problem isn't really lack of illumination, but that you're not prepared >>> to accept the consequences of the explanation. >> >> Hilarity and riot. >> >>> >>> Here's my version of the illumination: >>> >> snip >>> -- It at least theoretically provides opportunities for compile-type (== >>> better) error messages if you accidentally pass a value of the wrong type. >>> >>> -- It at least theoretically eliminates the need to code some range >>> validation checks. >>> >> >> Here is a nice instance that I think quite germane. >> >> The input parameter to NSArray's objectAtIndex: is an NSUInteger. >> Both these code snippets work perfectly (they retrieve element 3). >> zStr = [zAry objectAtIndex:3.1]; >> and >> CGFloat zF1 = 3.2; >> zStr = [zAry objectAtIndex:zF1]; >> >> I'm sure that by setting the right flags one could get warning messages to >> appear. > > > Julius, > > As others have pointed out, this has nothing to do with Objective-C or Cocoa. NSArray and its count method has nothing to do with Cocoa? I'm off to save a few sheep off the Antrim coast. Julius http://juliuspaintings.co.uk ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On May 30, 2011, at 13:45, julius wrote:
> Hilarity and riot.
Glad to have been of service.
> Here is a nice instance that I think quite germane.
>
> The input parameter to NSArray's objectAtIndex: is an NSUInteger.
> Both these code snippets work perfectly (they retrieve element 3).
> zStr = [zAry objectAtIndex:3.1];
> and
> CGFloat zF1 = 3.2;
> zStr = [zAry objectAtIndex:zF1];
>
> I'm sure that by setting the right flags one could get warning messages to
> appear.
OK, but why are you picking on NSArray? Here's another method that exemplifies
exactly the same problem:
- (id) iMadeThisUp: (unsigned int) theNumberIFirstThoughtOf { ... }
It's a defect in ObjC that comes directly from a defect in C.
Now that we've reduced this to a C issue, let me try to provoke more hilarity
and riot by re-characterizing your objection:
-- You want integer calculations in C to be carried out in a unique abstract
numerical space.
By "unique", I mean that there aren't different rules depending on the types of
the integers involved. By "abstract" I mean that the numerical range is
conceptually infinite. The only constraint is that the result should be
representable in (?) the variable type of the destination variable, or
something like that.
This is a perfectly sensible idea. It is in fact a lot like how C works with
floating point -- intermediate calculations are performed in type 'double',
even if the values are type 'float'. In effect, C has no "arithmetic" type
'float', only a "storage" type 'float'. (Terminology applied loosely here.)
Unfortunately, somebody decided a long time ago, the same can't be done for
integers, because there's no infinite-range numerical space available to
machine computation (in any way that mainstream hardware supports directly),
and no single finite-range space that (as in the floating point case)
encompasses the others.
As a result, in C, the numerical space of the expression really does depend on
the types of the variables involved. The arithmetic operators, even + and -,
*mean* different things for signed and unsigned arithmetic. You should read
that last sentence twice, because it's the heart of the matter.
There is, additionally, a horrible mish-mash of conversion rules that mean that
much of the time you can ignore the difference when writing source code, but at
your peril.
You want different conversion rules? Fine. You want warning messages? Fine. You
want a unique abstract numerical space? Fine. You want type-independent
arithmetic operators? Fine. You want to get us a new language? Fine. But you
can't insist of writing code for a
language-roughly-similar-to-C-but-not-quite-the-same-thing and then complain
because it isn't C. *There's* the riot and hilarity. ;)
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
Maybe this will assuage your outrage (excuse the lame programmer poetry): If you were to look at the apis for NSArray and see that indices are signed integers, you could reasonably conclude that storing/retrieving an object from a negative index is a legitimate thing to do. That would maybe be a fun capability, but then it raises questions like is the array zero-based or what? Etc. Starting to make more sense? _murat On May 30, 2011, at 2:10 PM, julius wrote: > > On 30 May 2011, at 21:56, Dave Zarzycki wrote: > >> On May 30, 2011, at 1:45 PM, julius wrote: >> >>> >>> On 30 May 2011, at 20:03,Quincey Morris wrote On May 30, 2011, at 08:27, julius wrote: > All I had hoped was that someone on this list might illuminate the issue > more than has happened so far. The problem isn't really lack of illumination, but that you're not prepared to accept the consequences of the explanation. >>> >>> Hilarity and riot. >>> Here's my version of the illumination: >>> snip -- It at least theoretically provides opportunities for compile-type (== better) error messages if you accidentally pass a value of the wrong type. -- It at least theoretically eliminates the need to code some range validation checks. >>> >>> Here is a nice instance that I think quite germane. >>> >>> The input parameter to NSArray's objectAtIndex: is an NSUInteger. >>> Both these code snippets work perfectly (they retrieve element 3). >>> zStr = [zAry objectAtIndex:3.1]; >>> and >>> CGFloat zF1 = 3.2; >>> zStr = [zAry objectAtIndex:zF1]; >>> >>> I'm sure that by setting the right flags one could get warning messages to >>> appear. >> >> >> Julius, >> >> As others have pointed out, this has nothing to do with Objective-C or Cocoa. > > NSArray and its count method has nothing to do with Cocoa? > > > I'm off to save a few sheep off the Antrim coast. > > Julius > > > http://juliuspaintings.co.uk > > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/mlist0987%40gmail.com > > This email sent to mlist0...@gmail.com ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On 30 May 2011, at 22:34, Quincey Morris wrote: > On May 30, 2011, at 13:45, julius wrote: > >> Hilarity and riot. > > Glad to have been of service. > >> Here is a nice instance that I think quite germane. >> >> The input parameter to NSArray's objectAtIndex: is an NSUInteger. >> Both these code snippets work perfectly (they retrieve element 3). >> zStr = [zAry objectAtIndex:3.1]; >> and >> CGFloat zF1 = 3.2; >> zStr = [zAry objectAtIndex:zF1]; >> >> I'm sure that by setting the right flags one could get warning messages to >> appear. > > OK, but why are you picking on NSArray? I was packed and almost out the door (off to save sheep in distress off the Antrim coast). I'm not picking on anybody. My question is Why did Cocoa developers make NSArray count return NSUInteger? Is it possible for me to be clearer than that? > > Now that we've reduced this to a C issue, No we have not. You think you have. > let me try to provoke more hilarity and riot by re-characterizing your > objection: > > -- You want integer calculations in C to be carried out in a unique abstract > numerical space. I'm definitely off to the north coast. Bye. Julius http://juliuspaintings.co.uk ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On May 30, 2011, at 15:14, julius wrote: > I'm definitely off to the north coast. I *wish* people would stop using that old "saving the distressed sheep" line to put an end to a thread. It's happening far too often these days. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
julius wrote: My question is Why did Cocoa developers make NSArray count return NSUInteger? It's impossible to answer with certainty. The person or persons who made that decision are not on this list (AFAIK). Nor have they documented the rationale behind their design decisions for posterity. Several hypotheses have been proposed. The simplest one is that the returned type is consistent with the parameter types of all the other methods that have an index parameter. You have countered with reasons why the various hypotheses are not compelling (in your opinion). Others have countered with reasons why your reasons are not compelling (in their opinion). Your taste is not theirs, nor is theirs yours. In a practical sense, none of this matters. The decision was made long, long ago. It is what it is. You're too late to save that sheep from drowning. -- GG ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Linearly Scaling Text
> Because it was mono-Font text, I resorted to scaling the font > instead. Actually I did try scaling the font instead of the text view, but I'm unable to get the text to scale linearly as our application should be able to handle most fonts. > I never went back to view scaling, but I wonder > if you could control the granularity of the involved CALayers such that a > tiled view would produce a clean result when scaled up? Just a thought. Hmm, there seems to be an issue scaling any layer-backed NSTextView, but I'll definitely look in to using a tiled layer. Thanks. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On 31/05/2011, at 8:57 AM, Greg Guerin wrote: > julius wrote: > >> My question is >> Why did Cocoa developers make NSArray count return NSUInteger? > > In a practical sense, none of this matters. The decision was made long, long > ago. It is what it is. You're too late to save that sheep from drowning. No API is perfect, and Cocoa is no exception. I learned a long time ago that it's a bit pointless to fret about the why and just understand how it is. That way, you get your apps written and out of the door. There are plenty of questionable and strange things in Cocoa that in hindsight could have been done better, or at least differently, but they weren't. In NSArray in particular, a more interesting thing which is both a good and bad thing depending on the hour of the day, is that you can't specify, find out or restrict the object types it holds. Obj-C has no syntax (as C++ does, for better or worse) for templating collection types. In practice this doesn't matter, even though sometimes it causes bugs, just as faulty signed/unsigned arithmetic causes bugs. In the end, no language can save you from yourself. --Graham ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
Nothing but mental masturbation ... give it a rest ... moderator, do your job, please. -koko On May 30, 2011, at 4:43 PM, Quincey Morris wrote: > On May 30, 2011, at 15:14, julius wrote: > >> I'm definitely off to the north coast. > > I *wish* people would stop using that old "saving the distressed sheep" line > to put an end to a thread. It's happening far too often these days. > > > ___ > > Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) > > Please do not post admin requests or moderator comments to the list. > Contact the moderators at cocoa-dev-admins(at)lists.apple.com > > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/cocoa-dev/koko%40highrolls.net > > This email sent to k...@highrolls.net > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
>Unfortunately, somebody decided a long time ago, the same can't be done for >integers, because there's no infinite-range numerical space available to >machine computation (in any way that mainstream hardware supports directly), >and no single finite-range space that (as in the floating point case) >encompasses the others. Smalltalk integers appeared to all be of the same Integer class, but behind the scenes they'd switch from primitive smallints to objects once they hit the smallint max (29 bits in 32-bit address space). But unless you were inside the virtual machine you couldn't tell objects from primitives anyway - every single thing you dealt with was an object. But in a hybrid like ObjC, we sometimes have to play by C rules. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Linearly Scaling Text
Actually, I wasn¹t talking about tiled layers, although that might also be relevant. I was talking about tiled views. There is some sample code available for tiled views, but it took some massaging to get it to do what I wanted. I only tiled my view vertically and used half of a screen height for each tile, so it only used three actual tiles to render a very long text view. I was thinking that maybe each view tile could be layer backed and (when squeezed down) use a high-density layer (if that¹s possible), so that it comes out right when scaled back up. On 5/30/11 7:14 PM, "Ajay Sabhaney" wrote: >> > Because it was mono-Font text, I resorted to scaling the font >> > instead. > > Actually I did try scaling the font instead of the text view, but I'm unable > to get the text to scale linearly as our application should be able to handle > most fonts. > >> > I never went back to view scaling, but I wonder >> > if you could control the granularity of the involved CALayers such that a >> > tiled view would produce a clean result when scaled up? Just a thought. > > Hmm, there seems to be an issue scaling any layer-backed NSTextView, but I'll > definitely look in to using a tiled layer. Thanks. > ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On 31/05/2011, at 11:06 AM, koko wrote: > Nothing but mental masturbation ... give it a rest ... moderator, do your > job, please. Get out of bed the wrong side today? Quincey is one of the most helpful contributors on the list; you might remember that next time you want help. There's always room for a little humour - if you don't want to read it don't (view by thread and just ignore it). --Graham___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Autoreleased Data In Cocoa
Dear all,
I have a question about autoreleased data in Cocoa. According to the
documentation from Apple.com, developers need to design autorelease pools
when programming command-line, loop and threading. If in Cocoa without
threading, no autorelease pools are programmed explicitly since an
autorelease pool is created by Cocoa. Am i right? If so, autoreleased data
has a life cycle as long as the process? What is the difference between
implicit autoreleasing and memory leaking?
I got a problem related to autorelease pools. My program works in Cocoa
without NSThread developed by me. The method received data remotely and then
returned data outside. I autoreleased the data before they were returned.
However, it got exceptions sometimes. If I did NOT autorelease them,
everything ran well. Could you give me a hand on this? The code is as
follows.
I appreciate so much for your help!
Best regards,
Bing
- (NSString *) receiveMessage
{
NSMutableString *receivedString;
NSString *message;
NSString *newReceivedString;
[isConnectedLock lock];
@try
{
if (isConnected)
{
char buffer[Constants.WWW.BUFFER_SIZE];
// Receive remote data
ssize_t numBytesReceived = recv(destinationSocket,
buffer, Constants.WWW.BUFFER_SIZE, 0);
if (numBytesReceived <= 0)
{
return Constants.WWW.NO_RECEIVED_MESSAGE;
}
buffer[numBytesReceived] = '\0';
// Convert data to NSString locally
receivedString = [[NSMutableString alloc]
initWithBytes:buffer length:numBytesReceived encoding:NSUTF8StringEncoding];
message = [[NSString alloc]
initWithString:Constants.WWW.EMPTY_STRING];
// Since the data has specific formats, some simple
parsing jobs by delimiter are done as follows.
NSRange range = [receivedString
rangeOfString:Constants.WWW.DELIMITER];
if (range.location > 0 && range.location <
[receivedString length])
{
message = [receivedString
substringToIndex:range.location];
// Return data after parsing
return message;
}
else
{
// Receive remote data continually if the
receivedString is longer than expected
while (numBytesReceived > 0)
{
NSAutoreleasePool *loopPool =
[[NSAutoreleasePool alloc] init];
// Receive data
numBytesReceived =
recv(destinationSocket, buffer, Constants.WWW.BUFFER_SIZE, 0);
if (numBytesReceived <= 0)
{
return
Constants.WWW.NO_RECEIVED_MESSAGE;
}
buffer[numBytesReceived] = '\0';
newReceivedString = [[[NSString
alloc] initWithBytes:buffer length:numBytesReceived
encoding:NSUTF8StringEncoding] autorelease];
range = [receivedString
rangeOfString:Constants.WWW.DELIMITER];
if (range.location > 0 &&
range.location < [receivedString length])
{
message = [receivedString
substringToIndex:range.location];
// Return data after parsing
return message;
}
[loopPool drain];
}
}
return Constants.WWW.NO_RECEIVED_MESSAGE;
}
else
{
return Constants.WWW.NO_RECEIVED_MESSAGE;
}
}
@catch (NSException *e)
{
return Constants.WWW.NO_RECEIVED_MESSAGE;
}
@finally
{
[isConnectedLock unlock];
// Before returning received data, autorelease them here.
[receivedString autorelease];
[message autorelease];
}
}
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Up
Re: Why does NSArray count return NSUInteger?
On May 30, 2011, at 9:38 PM, Graham Cox wrote: > On 31/05/2011, at 11:06 AM, koko wrote: > >> Nothing but mental masturbation ... give it a rest ... moderator, do your >> job, please. > > > Get out of bed the wrong side today? > > Quincey is one of the most helpful contributors on the list; you might > remember that next time you want help. There's always room for a little > humour - if you don't want to read it don't (view by thread and just ignore > it). Graham, I'm not sure koko's remark was directed at Quincey. I think koko was agreeing with Greg: the question presented is one that is not answerable on this list. No one here can speak to the mental processes that underlay design decisions made long ago. The thread is therefore appropriate for moderation. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to extract files from zip archive?
On May 30, 2011, at 8:45 AM, Vyacheslav Karamov wrote: > NSString * listsPath = STR_ADDPATH([[NSBundle mainBundle] resourcePath], > @"lists.zip"); What is STR_ADDPATH? There's already Cocoa API for what it looks like it does: NSString *listsPath = [[NSBundle mainBundle] pathForResource:@"lists" ofType:@"zip"]; In general you shouldn't try to reinvent or wrap Cocoa's APIs. > NSArray * args = [NSArray arrayWithObjects:@"-a ", listsPath, @" -d ", > sharedPath, nil]; NSTask does not perform any shell interpretation on the arguments you give it; you do not need to use spaces, quotes, etc. in them. This is general to Unix-based operating systems: Only a very few APIs (such as the system(3) function) do any sort of argument interpretation. In general, if you're dealing with an array of arguments, that's the array that will be copied (via the execve(2) or posix_spawn(2) functions) over to the other program's main() function. -- Chris ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Why does NSArray count return NSUInteger?
On May 30, 2011, at 6:57 PM, Greg Guerin wrote: > julius wrote: > >> My question is >> Why did Cocoa developers make NSArray count return NSUInteger? > > > It's impossible to answer with certainty. The person or persons who made > that decision are not on this list (AFAIK). Nor have they documented the > rationale behind their design decisions for posterity. Exactly. If you're asking "What was the state of mind of the person or persons who made that decision, at the time they made it?" then sorry, that answer seems not to be forthcoming. Maybe if you keep repeating the question you'll get the answer, but I wouldn't count on it. If you're asking "Is there an ironclad argument for doing it that way that will answer all my objections?" then sorry, the answer is very obviously no, or at least it should have been obvious long ago in this thread. If you're asking "Are there *any* reasons for doing it that way?" then the answer is very obviously yes. If those reasons don't satisfy you, then once again... sorry. --Andy ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: How to extract files from zip archive?
On Mon, May 30, 2011 at 10:45 AM, Vyacheslav Karamov wrote: > Hi All! > ... > [task setLaunchPath:@"/usr/bin/unzip"]; > NSArray * args = [NSArray arrayWithObjects:@"-a ", listsPath, @" -d ", > sharedPath, nil]; In addition to what others have said regarding spaces and such, when I was looking around for this, most of the posts at various sources suggested using ditto as opposed to unzip. Someone can correct me if I'm wrong, but AFAIK unzip doesn't support resource forks (though you can unzip 'em to a separate file), and there may be other metadata it ignores/goofs up/forgets/etc. Launching ditto to do this is easy: [task setLaunchPath:@"/usr/bin/ditto"]; [task setArguments: [NSArray arrayWithObjects:@"-x", @"-k", zipFilePath, someTargetDirectory, nil] ]; -Jim ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Autoreleased Data In Cocoa
On May 30, 2011, at 8:15 PM, Bing Li wrote:
> - (NSString *) receiveMessage
> {
>NSMutableString *receivedString;
>NSString *message;
>NSString *newReceivedString;
>[isConnectedLock lock];
>@try
>{
>if (isConnected)
>{
>char buffer[Constants.WWW.BUFFER_SIZE];
>
>// Receive remote data
>ssize_t numBytesReceived = recv(destinationSocket,
> buffer, Constants.WWW.BUFFER_SIZE, 0);
>if (numBytesReceived <= 0)
>{
>return Constants.WWW.NO_RECEIVED_MESSAGE;
>}
>buffer[numBytesReceived] = '\0';
>
>
>// Convert data to NSString locally
>receivedString = [[NSMutableString alloc]
> initWithBytes:buffer length:numBytesReceived encoding:NSUTF8StringEncoding];
>message = [[NSString alloc]
> initWithString:Constants.WWW.EMPTY_STRING];
Why are you storing a non-autoreleased object to a pointer and then writing
over it later?
>
>
>// Since the data has specific formats, some simple
> parsing jobs by delimiter are done as follows.
>
>NSRange range = [receivedString
> rangeOfString:Constants.WWW.DELIMITER];
>if (range.location > 0 && range.location <
> [receivedString length])
>{
>message = [receivedString
> substringToIndex:range.location];
Here you're overwriting a pointer to an object you own with an autoreleased
object.
>
>// Return data after parsing
>return message;
>}
>else
>{
>// Receive remote data continually if the
> receivedString is longer than expected
>while (numBytesReceived > 0)
>{
>NSAutoreleasePool *loopPool =
> [[NSAutoreleasePool alloc] init];
>
>// Receive data
>numBytesReceived =
> recv(destinationSocket, buffer, Constants.WWW.BUFFER_SIZE, 0);
>if (numBytesReceived <= 0)
>{
>return
> Constants.WWW.NO_RECEIVED_MESSAGE;
Here you're leaking the autorelease pool you created above.
>}
>
>
>buffer[numBytesReceived] = '\0';
>newReceivedString = [[[NSString
> alloc] initWithBytes:buffer length:numBytesReceived
> encoding:NSUTF8StringEncoding] autorelease];
>range = [receivedString
> rangeOfString:Constants.WWW.DELIMITER];
>if (range.location > 0 &&
> range.location < [receivedString length])
>{
>message = [receivedString
> substringToIndex:range.location];
>
>// Return data after parsing
>return message;
Here you're placing a new object in the autorelease pool, and then leaking the
autorelease pool.
>}
>[loopPool drain];
>}
>}
>return Constants.WWW.NO_RECEIVED_MESSAGE;
>}
>else
>{
>return Constants.WWW.NO_RECEIVED_MESSAGE;
>}
>}
>@catch (NSException *e)
>{
>return Constants.WWW.NO_RECEIVED_MESSAGE;
>}
>@finally
>{
>[isConnectedLock unlock];
>
>// Before returning received data, autorelease them here.
>[receivedString autorelease];
>[message autorelease];
Here you're autoreleasing a pointer that may or may not have been autoreleased
already.
I suggest you re-read the memory management rules again and pay attention to
the rules regarding release and autorelease. If anyone tries to re-state it
here, we're inevitably going to get something wrong.
Also, I cannot recommend writing an object to a pointer that the program is
never going to read. If you're concerned about accidentally accessing an
uninitialized pointer, then just set it to nil instead.
Nick Zitzmann
Handling mouse events on transparent window conditionally
Hi, I am developing an Desktop application in which I should be able to take mouse events on transparent window. But, transparent NSWindow does not take mouse events. So, I have set setIgnoreMouseEvents to NO which allows the transparent window to take mouse events. I have the problem in the following scenario: There is dynamically created rectangular shape on this window. The transparent window should not take mouse events in this region; it should be delegated to the window (of some other app) that is present behind this shape. For this purpose, if the mouseDown event is inside the shape I am setting setIgnoreMouseEvents to YES. Now, if the user performs mouse events in the area outside the shape the transparent window should take the event. Since, setIgnoreMouseEvents is set to YES, window does not take mouse events. There is no way to identify that mouseDown event has occurred so that I can set setIgnoreMouseEvents to NO. Could someone suggest me some best method to handle mouse events on transparent window? Thanks and Regards, Deepa--- Robosoft Technologies - Come home to Technology Disclaimer: This email may contain confidential material. If you were not an intended recipient, please notify the sender and delete all copies. Emails to and from our network may be logged and monitored. This email and its attachments are scanned for virus by our scanners and are believed to be safe. However, no warranty is given that this email is free of malicious content or virus. ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
