Re: 64-bit iOS
This is the contrary. In Obj-c all pointers are effectively double size, but in Java, they are not. See “Compressed oops at http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-enhancements-7.html Le 11 sept. 2013 à 00:18, Paul Franz paul.p.fr...@gmail.com a écrit : Should be interesting to see how this plays out. When it comes to Java, when you switch from a 32-bit JVM to a 64-bit JVM there is a 10% penalty doing so. The main reason has to do with pointers. All pointers double in size. The effect might be less in a Objective-C program. Paul Franz On Sep 10, 2013, at 5:47 PM, Tom Davie tom.da...@gmail.com wrote: On 10 Sep 2013, at 23:30, Jean-Daniel Dupas devli...@shadowlab.org wrote: For ARM, 64 bit matters because the instruction set has been updated to provider better performances. I just hope the performance boost provided by this architecture change will be enough to balance the slow-down due to the increase of instruction and pointer size. Note, this was actually more significant on x86, where most of the mess caused by CISC (like having bugger all registers) got sorted out. Tom Davie ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/paul.p.franz%40gmail.com This email sent to paul.p.fr...@gmail.com -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Hi John! On Sep 10, 2013, at 19:26 , John McCall rjmcc...@apple.com wrote: On Sep 9, 2013, at 4:15 AM, Marcel Weiher marcel.wei...@gmail.com wrote: [Optimizations in ARC are there to mitigate pessimizations] For what it’s worth, the autorelease optimization was planned; the performance problem it solves was extremely predictable, since it’s actually a noticeable performance problem in MRC code as well. Glad to hear that the performance problems that the optimizations were designed to mitigate were identified early, hope this also resulted in fewer Café Macs dinner tickets. :-) Worth noting: trying to micro-optimize retains and releases by naively opting files out of ARC is a great way to defeat the autorelease optimization; if you do this and care about performance, I strongly suggest using +1 returns. I don’t think that would be a good target or reason for opting out. In fact, I have a protocol where I have a +1 return that I am thinking of turning ARC on for so I don’t have to do that any longer. :-) More likely performance reasons/targets for opting out are things like inline reference counts and, especially, object caches. For me they generally bring factors of improvement, if not orders of magnitude, when applicable (wasn’t it CoreGraphics that had problems with their object cache no longer working on GC, thus killing performance?) Being able to mix-n-match and opt out is definitely one of the awesome features of ARC. On the inline reference counts: when I was doing my recent tests on archiving performance, I suddenly found that object creation (1M objects) was taking longer than expected. Adding an inline retain count *halved* the running time for creating the object graph (155ms vs 300ms)! I have to admit I was bit surprised that the difference would be this big, considering the intrinsic cost of object creation.(Out of curiosity I tested it with ARC and it took 400ms) Also of note: the ARC optimizer relies on being able to see how objects are used, so code that’s using dusty old “I don’t ever want to write retain/releases workarounds like literally making every temporary variable a property is basically asking to be pessimized. You misunderstand (I am likely blame for that for not expressing myself clearly): the temporary variables I use accessors for are the (very few) ones that have strange enough lifetimes that you see retain/release code for them in the middle of methods. Quite often, they already live in instance variables, but are just accessed in an ad-hoc fashion. Using accessors for them really is (or should be) a no-brainer. Sometimes there are asynchronous loops that use a local variable in a similar fashion. Using instance variables for ALL method temporaries would be silly…in essence it would be using the ARC strategy, but without the optimizer running to get rid of most of the damage, ouch! Overall, while we’re happy to see that some people see performance improvements, our expectation going in was always that ARC would cause some regressions, That is also what I would have expected, given what I know about it. It’s interesting that the “group consensus” I find both on the webs/tutorials and also here, sometimes tacit, sometimes not, is that ARC is a performance win. Note how the claim that ARC was faster went unremarked, whereas the finding of a slowdown created immediate negative reaction (“did you test?”, “you must have made a mistake”), fortunately mostly in good humor. and that while in most code those would be lost in the noise, in some cases people would need to help ARC out with things like __unsafe_unretained. Hmm…I always thought that __unsafe_unretained was for instance variables, but given what you just wrote, I guess it could be used for normal automatic variables to opt them out of ARC? Ultimately, ARC is just a tool for improving your productivity as a programmer, not a magic button with no downsides. ;-) Cheers, Marcel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSWindowCloseButton and friends mouse over highlight
On Sep 10, 2013, at 10:34 PM, dangerwillrobinsondan...@gmail.com wrote: However, sending highlight:YES to the button or setHighlighted:YES to the button cell, both give the mouse down image of the traffic light buttons. Is there something I'm missing in the docs or documented in a header somewhere? “Highlight” doesn't mean “mouse tracking” in AppKit. It means “mouse down”. Try sending -mouseEntered: and -mouseExited: to the button’s cell. --Kyle Sluder ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: NSWindowCloseButton and friends mouse over highlight
On Sep 11, 2013, at 4:15 PM, Kyle Sluder k...@ksluder.com wrote: On Sep 10, 2013, at 10:34 PM, dangerwillrobinsondan...@gmail.com wrote: However, sending highlight:YES to the button or setHighlighted:YES to the button cell, both give the mouse down image of the traffic light buttons. Is there something I'm missing in the docs or documented in a header somewhere? “Highlight” doesn't mean “mouse tracking” in AppKit. It means “mouse down”. Try sending -mouseEntered: and -mouseExited: to the button’s cell. --Kyle Sluder Thanks Kyle, I tried that. It doesn't have any visible effect. :( ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 11, 2013, at 12:03 AM, Marcel Weiher marcel.wei...@gmail.com wrote: On Sep 10, 2013, at 19:26 , John McCall rjmcc...@apple.com wrote: On Sep 9, 2013, at 4:15 AM, Marcel Weiher marcel.wei...@gmail.com wrote: [Optimizations in ARC are there to mitigate pessimizations] For what it’s worth, the autorelease optimization was planned; the performance problem it solves was extremely predictable, since it’s actually a noticeable performance problem in MRC code as well. Glad to hear that the performance problems that the optimizations were designed to mitigate were identified early, hope this also resulted in fewer Café Macs dinner tickets. :-) Fortunately. :) Worth noting: trying to micro-optimize retains and releases by naively opting files out of ARC is a great way to defeat the autorelease optimization; if you do this and care about performance, I strongly suggest using +1 returns. I don’t think that would be a good target or reason for opting out. In fact, I have a protocol where I have a +1 return that I am thinking of turning ARC on for so I don’t have to do that any longer. :-) I think we’re in agreement here. More likely performance reasons/targets for opting out are things like inline reference counts and, especially, object caches. For me they generally bring factors of improvement, if not orders of magnitude, when applicable (wasn’t it CoreGraphics that had problems with their object cache no longer working on GC, thus killing performance?) On the inline reference counts: when I was doing my recent tests on archiving performance, I suddenly found that object creation (1M objects) was taking longer than expected. Adding an inline retain count *halved* the running time for creating the object graph (155ms vs 300ms)! I have to admit I was bit surprised that the difference would be this big, considering the intrinsic cost of object creation.(Out of curiosity I tested it with ARC and it took 400ms) Right. ARC doesn’t replace the benefit of having an inline reference count. I think if we could magically bless all objects with an inline reference count without worrying about disrupting existing hard-coded object layouts, we probably would. Also of note: the ARC optimizer relies on being able to see how objects are used, so code that’s using dusty old “I don’t ever want to write retain/releases workarounds like literally making every temporary variable a property is basically asking to be pessimized. You misunderstand (I am likely blame for that for not expressing myself clearly): the temporary variables I use accessors for are the (very few) ones that have strange enough lifetimes that you see retain/release code for them in the middle of methods. Quite often, they already live in instance variables, but are just accessed in an ad-hoc fashion. Using accessors for them really is (or should be) a no-brainer. Sometimes there are asynchronous loops that use a local variable in a similar fashion. Using instance variables for ALL method temporaries would be silly…in essence it would be using the ARC strategy, but without the optimizer running to get rid of most of the damage, ouch! We’ve definitely seen some odd contortions to avoid a few explicit retain/releases. Overall, while we’re happy to see that some people see performance improvements, our expectation going in was always that ARC would cause some regressions, That is also what I would have expected, given what I know about it. It’s interesting that the “group consensus” I find both on the webs/tutorials and also here, sometimes tacit, sometimes not, is that ARC is a performance win. Note how the claim that ARC was faster went unremarked, whereas the finding of a slowdown created immediate negative reaction (“did you test?”, “you must have made a mistake”), fortunately mostly in good humor. and that while in most code those would be lost in the noise, in some cases people would need to help ARC out with things like __unsafe_unretained. Hmm…I always thought that __unsafe_unretained was for instance variables, but given what you just wrote, I guess it could be used for normal automatic variables to opt them out of ARC? Absolutely. We’ve found that it usually doesn’t take very many __unsafe_unretained annotations to eliminate most regressions. There are a ton of places where any human reading the code would immediately realize that an object won’t get released, but ARC can’t quite prove that, usually because there’s an intervening message send. Most of those places don’t detectably affect performance; it’s the one or two that happen in a loop and therefore trigger 40,000 times that you notice. But by the same token, those sites tend to show up in Instruments and so are easy to track down and fix. John. ___ Cocoa-dev mailing list
Re: 64-bit iOS
Mostly, this is not going to change anything. You will see your code size increase, because unless you use PIC, you’ll have to store 64-bit addresses instead of 32. There will be more cache misses as your memory space becomes sparse. It will surely run faster, but not because the bus size has been increased, but because the number of GPR is doubled, thereby allowing some optimizations during scheduling and context switching. But what bother me most, is that I don’t really see the point. A smartphone is a phone, it is neither a web server nor a huge database machine nor a supercomputer. Who wants to mmap 5 GiB files on a phone? Which process needs more than 2 GiB at most? Seriously? Will it make you reading your mail faster, loading webpages instantaneously? Will your calendar feel snappier? Besides marketing and advertisement, nobody really needs that amount of power. We’re not going to simulate galaxy dynamics on an iPhone, or derive the flow lines around the next fighter of the US Air Force… The iPhone 3S already delivers a more than sufficient experience for the vast majority of users. Besides, embedded programming is about optimizing and stuffing the most in the tiniest space… Vincent ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
Le 11 sept. 2013 à 09:03, Marcel Weiher marcel.wei...@gmail.com a écrit : Hi John! On Sep 10, 2013, at 19:26 , John McCall rjmcc...@apple.com wrote: On Sep 9, 2013, at 4:15 AM, Marcel Weiher marcel.wei...@gmail.com wrote: [Optimizations in ARC are there to mitigate pessimizations] For what it’s worth, the autorelease optimization was planned; the performance problem it solves was extremely predictable, since it’s actually a noticeable performance problem in MRC code as well. Glad to hear that the performance problems that the optimizations were designed to mitigate were identified early, hope this also resulted in fewer Café Macs dinner tickets. :-) Worth noting: trying to micro-optimize retains and releases by naively opting files out of ARC is a great way to defeat the autorelease optimization; if you do this and care about performance, I strongly suggest using +1 returns. I don’t think that would be a good target or reason for opting out. In fact, I have a protocol where I have a +1 return that I am thinking of turning ARC on for so I don’t have to do that any longer. :-) More likely performance reasons/targets for opting out are things like inline reference counts and, especially, object caches. For me they generally bring factors of improvement, if not orders of magnitude, when applicable (wasn’t it CoreGraphics that had problems with their object cache no longer working on GC, thus killing performance?) Being able to mix-n-match and opt out is definitely one of the awesome features of ARC. On the inline reference counts: when I was doing my recent tests on archiving performance, I suddenly found that object creation (1M objects) was taking longer than expected. Adding an inline retain count *halved* the running time for creating the object graph (155ms vs 300ms)! I have to admit I was bit surprised that the difference would be this big, considering the intrinsic cost of object creation.(Out of curiosity I tested it with ARC and it took 400ms) Also of note: the ARC optimizer relies on being able to see how objects are used, so code that’s using dusty old “I don’t ever want to write retain/releases workarounds like literally making every temporary variable a property is basically asking to be pessimized. You misunderstand (I am likely blame for that for not expressing myself clearly): the temporary variables I use accessors for are the (very few) ones that have strange enough lifetimes that you see retain/release code for them in the middle of methods. Quite often, they already live in instance variables, but are just accessed in an ad-hoc fashion. Using accessors for them really is (or should be) a no-brainer. Sometimes there are asynchronous loops that use a local variable in a similar fashion. Using instance variables for ALL method temporaries would be silly…in essence it would be using the ARC strategy, but without the optimizer running to get rid of most of the damage, ouch! Overall, while we’re happy to see that some people see performance improvements, our expectation going in was always that ARC would cause some regressions, That is also what I would have expected, given what I know about it. It’s interesting that the “group consensus” I find both on the webs/tutorials and also here, sometimes tacit, sometimes not, is that ARC is a performance win. Note how the claim that ARC was faster went unremarked, whereas the finding of a slowdown created immediate negative reaction (“did you test?”, “you must have made a mistake”), fortunately mostly in good humor. I think this common misbelief come from the fact that when Apple released ARC, they have claimed a non negligible performance win for retain/release and autorelease operations. While this is true, it does not give any clue about the global impact of ARC. and that while in most code those would be lost in the noise, in some cases people would need to help ARC out with things like __unsafe_unretained. Hmm…I always thought that __unsafe_unretained was for instance variables, but given what you just wrote, I guess it could be used for normal automatic variables to opt them out of ARC? Yes. it works to disable ARC for arguments and other local variables. I managed to reduce the ARC impact a little further by applying it to some arguments in hot paths. -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 64-bit iOS
Le 11 sept. 2013 à 11:31, Vincent Habchi vi...@macports.org a écrit : Mostly, this is not going to change anything. You will see your code size increase, because unless you use PIC, you’ll have to store 64-bit addresses instead of 32. There will be more cache misses as your memory space becomes sparse. It will surely run faster, but not because the bus size has been increased, but because the number of GPR is doubled, thereby allowing some optimizations during scheduling and context switching. The increase of GPR is far to be the only architecture change between arm7 and AArch64 (assuming AArch64 is what Apple is using). But what bother me most, is that I don’t really see the point. A smartphone is a phone, it is neither a web server nor a huge database machine nor a supercomputer. Who wants to mmap 5 GiB files on a phone? Which process needs more than 2 GiB at most? Seriously? Will it make you reading your mail faster, loading webpages instantaneously? Will your calendar feel snappier? Besides marketing and advertisement, nobody really needs that amount of power. We’re not going to simulate galaxy dynamics on an iPhone, or derive the flow lines around the next fighter of the US Air Force… The iPhone 3S already delivers a more than sufficient experience for the vast majority of users. Besides, embedded programming is about optimizing and stuffing the most in the tiniest space… Thanks for this remainder, but I think we all already know that 620k is enough for anyone… -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
AuthorizationExecuteWithPrivileges deprecated
I have this code:
AuthorizationRefauth;
OSStatus aa = AuthorizationCreate( NULL, kAuthorizationEmptyEnvironment,
kAuthorizationFlagDefaults, auth);
const char *pathToTool = [ theHelperPath fileSystemRepresentation ];
const char *const arguments[] = { --self-repair, NULL };
FILE *communicationsPipe;
aa = AuthorizationExecuteWithPrivileges ( auth,
pathToTool,
kAuthorizationFlagDefaults,
(char * const *)arguments,
communicationsPipe
);
int fileDescriptor = fileno( communicationsPipe );
NSFileHandle *readHandel = [ [ NSFileHandle alloc ] initWithFileDescriptor:
fileDescriptor ];
... some reading from readHandel
int yy = fclose( communicationsPipe );
works fine, but Xcode is telling me that AuthorizationExecuteWithPrivileges is
deprecated since 10.7.
I asked Xcode about this (expecting something like: use this instead) but got
no answer.
So what to do?
My HelperTool needs to run as root. How is this to be done?
Gerriet.
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 11 Sep 2013, at 05:04, Jens Alfke j...@mooseyard.com wrote: On Sep 10, 2013, at 12:33 PM, Dave d...@looktowindward.com wrote: You with all this talk of memory management, you'd think that Apple (or someone) would have come up with a hardware solution for this by now. In the 70's and 80's I worked on some firmware and hardware that would handle garbage collection in real time (with a little help from OS Software). I’ve read through a lot of GC papers in the past, and I’m not sure what you’re talking about here, unless it’s something that allows extra tag bits to be stored in pointers. This was used a lot in old LISP systems; it can be useful with interpreted languages but I don’t think it’d be applicable to a C-based language. (A lot of the more sophisticated GC techniques simply don’t work with C-like code because it’s too low-level and makes too many assumptions about memory. For example, you can’t use compaction or copying collectors at all because objects can’t be relocated. The Obj-C garbage collector had to rely on inefficient conservative mark/sweep algorithms.) This was using aUnix Box/MS-DOS box and it was our own hardware, and yes it worked with C and Assembler (via a set of Macro's). Basically it was a lump of hardware that controlled allocating memory from a pool. It wasn't used for system memory (although it could have been), but as a way of speeding up certain Image Processing operations. Basically it could allocate or free a memory block in one machine cycle - it could also copy or fill a block much faster then the CPU too. If Apple were to implement something like this I think there would be a massive increase in performance and reliability Nothing personal, but I think you’re falling into the common fallacy of thinking that Apple engineers are naive and/or ignorant. It happens all the time on these lists. In general, you should assume that the people working on system software are pretty damn smart and experienced, and are aware of all the techniques that an interested but non-expert outsider would know of. If they’re not using them, there’s probably a good reason for it. I'm sure the engineers are a mixture of good, mediocre, and not so good the same as any where else, why should Apple be different? But engineers don't get much say on what projects/features are implemented (especially somewhere like Apple, MS or any of the big 5 technology companies). (This is a special case of the nearly universal engineer’s fallacy of dismissing any problem you haven’t personally worked on as trivial.) I personally worked on these problems and I don't consider the trivial. Cheers Dave ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On 11 Sep 2013, at 11:37, Jean-Daniel Dupas devli...@shadowlab.org wrote: Yes. it works to disable ARC for arguments and other local variables. I managed to reduce the ARC impact a little further by applying it to some arguments in hot paths. -- Jean-Daniel I would have thought that you would get most bang for your buck by optimising decalloc methods? If I've understood what is being said: [someObject someMehtod:,myObject]; Causes the compiler to add extra retains? If so, then, in my experience, dealloc tends to triggers the release of a whole network of dealloc's and if they are all doing the same extra retain calls, then it would surely impact performance? Cheers Dave ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Crashing Problem calling postNotificationName
Hi,
Sorry for the lack of data in my original post! I Found the problem it was a
Notification being sent to a dead object, it didn't happen very often, one
crash after over an hour running continuously. I was more worried about the
data I was passing not belonging to same thread (I recently added this code)
rather than one the object being dead. I thought my modifications had caused
the crash, but actually it was there all along hiding!
Is there any problem with having all notifications handled by one object that
doesn't go away, and have this ship the notificationa off to the correct object
as long as it is still alive? The way this App is designed is I can tell if the
object is allocated or not and if it is allocated, then I want it to receive
notifications (In fact I ideally want it to get the last notifications sent
regardless of if the receiver was dead or alive when the event occurred). At
the moment I listen for the notification when the object is born and stop it
listening when it dies. But when it it dies I have to save the data from the
last notification somewhere and restore it when it is reincarnated. This is
common to around 26 classes and I don't want to change all 26 to do the above,
I'd rather the last value was remembered by the source of the notification and
resent somehow on request.
Any ideas?
Cheers
Dave
On 10 Sep 2013, at 12:08, Dave d...@looktowindward.com wrote:
Hi,
I have a crashing problem when calling postNotificationName, the following
method is called from an Operation Queue method/thread. It is called on the
Main Thread (the operation queue method, uses performSelectorOnMainThread
which calls parseOperationCompleted below. I've tried copying
theResultDictionary or just passing it in the dictionary as is, same result.
Any ideas what could be causing the crash?
-(void) parseOperationComplete:(NSDictionary*) theResultDictionary
{
myUserInfoDictionary = [[NSMutableDictionary alloc] init];
[myUserInfoDictionary setObject:self.pUpdateString
forKey:kUserInfoLiveUpdateString];
[myUserInfoDictionary setObject:[theResultDictionary copy]
forKey:kUserInfoLiveUpdateDictionary];
[NSNotificationCenter defaultCenter] postNotificationName:kNotificationName
object:self userInfo:myUserInfoDictionary];
}
Thanks in advance for any help!
All the Best
Dave
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/dave%40looktowindward.com
This email sent to d...@looktowindward.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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: 64-bit iOS
Thanks for this remainder, but I think we all already know that 620k is enough for anyone… Frankly, Jean-Daniel, I don’t want to get involved in a pointless bickering, but all I need on a phone was almost already running twenty-five years ago on my first Atari 520ST with, yes, 512 KiB of RAM. Cheers! Vincent ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 64-bit iOS
On 11 Sep, 2013, at 5:31 pm, Vincent Habchi vi...@macports.org wrote: But what bother me most, is that I don’t really see the point. A smartphone is a phone, it is neither a web server nor a huge database machine nor a supercomputer. Who wants to mmap 5 GiB files on a phone? Which process needs more than 2 GiB at most? Seriously? I see this as one step in a process. 64 bit architecture will trickle down from power chips to mobile chips just the way other changes have. There's sense in standardising on one architecture throughout the line, especially with the interoperability of large parts of OSX and iOS and who can say whether some grandchild of the chips we have in the mobile devices will end up powering the next range of multi-core mac pros or some other device. 64 bit is where it's going across the board, all chips will follow. Remembering the conversion to 64 bit in OSX, this doesn't happen overnight. Apps stay in the appstore and run on old hardware for years. I just read the transition guide and took a deep breath, never fun, it'll be quite a while before 64 bit apps are the norm and so it seems like a good plan to start biting the bullet now there's the first chip which supports it so that when 32 bit is ready to go away, most everything will be ready for the future. I'm not sure the examples of 4Gb mmap()ed files and huge processes on mobile devices are necessarily the best examples. There are speed advantages you can gain, a match between processor hardware and GPU hardware helps there too, if I can get 10% or more extra power out of one core, that delays the day I have to add another one. Anyway I see this as future proofing and a drive towards convergence of hardware and software to one architecture. I sure hope 64 bit lasts longer than some of the previous ones when we all get there, I really don't want to have to figure out what a long long long long long long long long int is before I hang up my keyboard. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Crashing Problem calling postNotificationName
On 2013 Sep 11, at 04:35, Dave d...@looktowindward.com wrote: the problem it was a Notification being sent to a dead object Yup. Is there any problem with having all notifications handled by one object that doesn't go away, and have this ship the notificationa off to the correct object as long as it is still alive? The way this App is designed is I can tell if the object is allocated or not and if it is allocated, then I want it to receive notifications (In fact I ideally want it to get the last notifications sent regardless of if the receiver was dead or alive when the event occurred). At the moment I listen for the notification when the object is born and stop it listening when it dies. But when it it dies I have to save the data from the last notification somewhere and restore it when it is reincarnated. This is common to around 26 classes and I don't want to change all 26 to do the above, I'd rather the last value was remembered by the source of the notification and resent somehow on request. In real-life apps, which do complicated things on multiple threads, removing KVO and notification observations at the appropriate time is often tricky. Ad hoc kludges are sometimes needed to supplement obvious design patterns such as remove observers during -dealloc. It looks like you're proposing a smart wrapper around the singleton NSNotificationCenter, and this is going to reduce the amount of code you write. Using a delegate or making these 26 classes inherit from a common superclass might be another way. Every app is different. It seems like you've thought this through. I would say to go ahead with it. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Crashing Problem calling postNotificationName
On 11/09/2013, at 1:35 PM, Dave d...@looktowindward.com wrote:
Is there any problem with having all notifications handled by one object that
doesn't go away,
Well, [NSNotificationCenter defaultCenter] is that object...
and have this ship the notificationa off to the correct object as long as it
is still alive? The way this App is designed is I can tell if the object is
allocated or not and if it is allocated, then I want it to receive
notifications
The correct way to deal with this is to remove yourself as a receiver of
notifications when you are deallocated. The documentation, in its roundabout
way, does state this.
- (void) dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
...
[super dealloc];
}
This pattern works without resorting to any odd hacks to avoid notifying a dead
object. Since that removes all possible notifications for 'self' it's a good
habit to add this automatically as soon as you add any notificaition
observations to your code.
--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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Crashing Problem calling postNotificationName
On 11 Sep 2013, at 13:55, Graham Cox graham@bigpond.com wrote:
On 11/09/2013, at 1:35 PM, Dave d...@looktowindward.com wrote:
Is there any problem with having all notifications handled by one object
that doesn't go away,
Well, [NSNotificationCenter defaultCenter] is that object…
Yes, but it doesn't remember the last value of a notification, which is what I
would like.
and have this ship the notificationa off to the correct object as long as it
is still alive? The way this App is designed is I can tell if the object is
allocated or not and if it is allocated, then I want it to receive
notifications
The correct way to deal with this is to remove yourself as a receiver of
notifications when you are deallocated. The documentation, in its roundabout
way, does state this.
- (void) dealloc
{
[[NSNotificationCenter defaultCenter] removeObserver:self];
...
[super dealloc];
}
This pattern works without resorting to any odd hacks to avoid notifying a
dead object. Since that removes all possible notifications for 'self' it's a
good habit to add this automatically as soon as you add any notificaition
observations to your code.
Yes, I am removing myself as a receiver, but ideally I want to receive these
notification even if the object is dead. By this I mean, I want the last known
value of the notification restored when the Object in question starts up again.
At present I have to save this somewhere ugly and restore it from somewhere
ugly. I just thought it would be nice to be able to just make a call something
like:
-(void) reissueLastNotificationName:@Note1 forClass:self
Rather than save it somewhere ugly 26 more times!
I could maybe subclass NSNotificationCenter?
All the Best
Dave
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Crashing Problem calling postNotificationName
On 11/09/2013, at 3:13 PM, Dave d...@looktowindward.com wrote: Yes, but it doesn't remember the last value of a notification, which is what I would like. [] Yes, I am removing myself as a receiver, but ideally I want to receive these notification even if the object is dead. By this I mean, I want the last known value of the notification restored when the Object in question starts up again. At present I have to save this somewhere ugly and restore it from somewhere ugly. I just thought it would be nice to be able to just make a call something like: -(void) reissueLastNotificationName:@Note1 forClass:self Rather than save it somewhere ugly 26 more times! I could maybe subclass NSNotificationCenter? There are a couple of statements here that don't make a huge amount of sense. What do you mean by an object….starts up again? Perhaps the problem is really that your object should not be being killed until the final notification has been received? That's a different problem. If you mean you want to save something between launches of your app so you can restore state, that's easily done by the sender of the notification. Basically, there isn't enough detail in your question to advise, and what you have given appears to smell a bit. Reissuing a notification sounds like a band-aid for a problem that should be solved some other way, to me. Subclassing NSNotificationCenter is presumably possible, but sounds like the wrong way to do whatever it is you are really trying to do. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Crashing Problem calling postNotificationName
On 11 Sep 2013, at 14:22, Graham Cox graham@bigpond.com wrote: On 11/09/2013, at 3:13 PM, Dave d...@looktowindward.com wrote: Yes, but it doesn't remember the last value of a notification, which is what I would like. [] Yes, I am removing myself as a receiver, but ideally I want to receive these notification even if the object is dead. By this I mean, I want the last known value of the notification restored when the Object in question starts up again. At present I have to save this somewhere ugly and restore it from somewhere ugly. I just thought it would be nice to be able to just make a call something like: -(void) reissueLastNotificationName:@Note1 forClass:self Rather than save it somewhere ugly 26 more times! I could maybe subclass NSNotificationCenter? There are a couple of statements here that don't make a huge amount of sense. What do you mean by an object….starts up again? I mean when the object is created - at this point I want the latest version of the Notification, not the Notification when the Object Died. Perhaps the problem is really that your object should not be being killed until the final notification has been received? That's a different problem. No, there is no final notification, just one when the data associated with it changes. If you mean you want to save something between launches of your app so you can restore state, that's easily done by the sender of the notification. No, I just want the latest version of the notification when the object is created. Yes, I could save it at the sender, but I'd still have the problem of restoring it when the object is created and wants to set itself to the current state. Basically, when it is created I want it to fetch the latest update and apply it to itself data at init time. I don't want to store the old value. Think like this: Object has not been created……….. Send Notification A Send Notification B Send Notification C Send Notification D Send Notification E Object is Created……….. Set Data from Notification E Send Notification F Object is Alive……….. Set Data from Notification F Send Notification G Object is Alive……….. Set Data from Notification G Object is deleted/released. Send Notification H Send Notification I Send Notification J Object is Created……….. Set Data from Notification J Basically, there isn't enough detail in your question to advise, and what you have given appears to smell a bit. Reissuing a notification sounds like a band-aid for a problem that should be solved some other way, to me. Subclassing NSNotificationCenter is presumably possible, but sounds like the wrong way to do whatever it is you are really trying to do. I want the above, I thought subclassing NSNotificationCenter and adding a memory would be quite a neat way of doing it - 27 times. All the Best Dave ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
ARC is a combination of compiler and runtime technologie. The compiler generates call to the runtime, so if you see a lot of ARC specific calls in the profiler, you can know if the impact is due to ARC or not. http://clang.llvm.org/docs/AutomaticReferenceCounting.html#runtime-support Le 11 sept. 2013 à 17:15, Sean Roehnelt s...@yellowmatter.com a écrit : ARC is compile time, not runtime, so I don't see how it could… On Sep 9, 2013, at 1:18 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: And does the profiler explicitly shows that ARC runtime code is the culprit ? -- Jean-Daniel ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: AuthorizationExecuteWithPrivileges deprecated
On Sep 11, 2013, at 5:53 AM, Gerriet M. Denkmann gerr...@mdenkmann.de wrote:
I have this code:
AuthorizationRef auth;
OSStatus aa = AuthorizationCreate( NULL, kAuthorizationEmptyEnvironment,
kAuthorizationFlagDefaults, auth);
const char *pathToTool = [ theHelperPath fileSystemRepresentation ];
const char *const arguments[] = { --self-repair, NULL };
FILE *communicationsPipe;
aa = AuthorizationExecuteWithPrivileges ( auth,
pathToTool,
kAuthorizationFlagDefaults,
(char * const *)arguments,
communicationsPipe
);
int fileDescriptor = fileno( communicationsPipe );
NSFileHandle *readHandel = [ [ NSFileHandle alloc ] initWithFileDescriptor:
fileDescriptor ];
... some reading from readHandel
int yy = fclose( communicationsPipe );
works fine, but Xcode is telling me that AuthorizationExecuteWithPrivileges
is deprecated since 10.7.
I asked Xcode about this (expecting something like: use this instead) but
got no answer.
So what to do?
My HelperTool needs to run as root. How is this to be done?
You have to use SMJobBless to install the tool as root, and then pick your
favorite form of IPC to communicate with it (XPC is best, if you can require
10.7).
Charles
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Slow down a scroller?
The Change Time Scale slider in Apple's Instruments application implements a novel self centering time based algorithm. A very interesting approach to a slider. Perhaps you also need to think outside the box and implement the desired behavior in a custom control. --Richard Somers On Jul 31, 2013, at 10:09 AM, Steve Mills smi...@makemusic.com wrote: Is there any way to make a scroller less touchy? ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Slow down a scroller?
Think about this. When in iTunes on an iOS device, and you are scrubbing an audio track, the farther down your finger is from the scrub knob, when you drag left and right, there is a multiplier to make the scrubbing slower. I'm thinking that in your case, you could use a scroll rate multiplier that changes depending on a measurement that you define. I think that you'd multiply by numbers 1, not use large numbers. On Sep 11, 2013, at 11:49 AM, Steve Mills wrote: I didn't get any responses when I sent this a few months ago. How about now? Is there any way to make a scroller less touchy? We have a couple cases where the horizontal scroller isn't controlling pixel movements of the view, but is used for more granular movements (rounded to the beginning of each measure in a musical score). It doesn't take much to flick it from 0 to 1 in this case, and it's impossible to swipe slowly enough to achieve measure-by-measure scrolls. I've tried multiplying the thumb proportion by even large numbers like 100, but it doesn't seem to affect its sensitivity at all. Any ideas? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/zav%40mac.com This email sent to z...@mac.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Sep 11, 2013, at 6:37 AM, Jean-Daniel Dupas devli...@shadowlab.org wrote: and that while in most code those would be lost in the noise, in some cases people would need to help ARC out with things like __unsafe_unretained. Hmm…I always thought that __unsafe_unretained was for instance variables, but given what you just wrote, I guess it could be used for normal automatic variables to opt them out of ARC? Yes. it works to disable ARC for arguments and other local variables. And you can put __unsafe_unretained objects in struct declarations, if you feel you must, and ARC won't complain. --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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Slow down a scroller?
On Sep 11, 2013, at 12:16:54, Kyle Sluder k...@ksluder.com
wrote:
Does calling -[NSScrolView set{Vertical,Horizontal}LineScroll:] not affect
the scroll wheel behavior?
Correct. It only affects the arrows that are no longer there. :)
If not, what about implementing -scrollWheel: in your document view?
Hmm, that's an idea. I've just added it and am getting results I didn't expect.
Here's the first event. Notice that deltaX is 0, but deviceDeltaX is -1, and
that's not a public member:
NSEvent: type=ScrollWheel loc=(421,512) time=183606.9 flags=0x100
win=0x263ceca0 winNum=18393 ctxt=0x224bb deltaX=0.00 deltaY=0.00
deltaZ=0.00 deviceDeltaX=-1.00 deviceDeltaY=0.00
deviceDeltaZ=0.00 count:0 phase=Began momentumPhase=None
When I stop scrolling I get this event:
NSEvent: type=ScrollWheel loc=(517,443) time=183608.2 flags=0x100
win=0x263ceca0 winNum=18393 ctxt=0x224bb deltaX=0.00 deltaY=0.00
deltaZ=0.00 deviceDeltaX=0.00 deviceDeltaY=0.00
deviceDeltaZ=0.00 count:0 phase=Ended momentumPhase=None
Note the phase=Begin and phase=End. So it's doing something special for views
contained in scroll views? We don't actually get anything usable until it calls
out scroller action, and the only thing we can do by that point is to inspect
the scroller's new value.
Furthermore, your document view is the same size as your scroll view? Is this
intentional? Because that's not how the scrolling architecture is designed to
work.
Yes, it's very intentional. Like I said, this is a different mode - only part
of the document view changes as the user scrolls horizontally. The left edge
remains static - it's where the staff names are listed.
--
Steve Mills
office: 952-818-3871
home: 952-401-6255
cell: 612-803-6157
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Slow down a scroller?
On Sep 11, 2013, at 12:49:49, Steve Mills smi...@makemusic.com wrote: Hmm, that's an idea. I've just added it and am getting results I didn't expect. Here's the first event. Notice that deltaX is 0, but deviceDeltaX is -1, and that's not a public member: Oh, I didn't know about the scrollingDelta* methods before, but that's also 0. WTH? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Crashing Problem calling postNotificationName
On Sep 11, 2013, at 6:52 AM, Dave d...@looktowindward.com wrote: I mean when the object is created - at this point I want the latest version of the Notification, not the Notification when the Object Died. NSNotification and the various Center classes are meant to be used for loosely coupling between classes. If you want to preserve state for your class, you need to do that yourself, and while you could encapsulate that in an NSNotification, it's overkill and causes you to think along lines for which the class was not designed. -- Gary L. Wade (Sent from my iPhone) http://www.garywade.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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Crashing Problem calling postNotificationName
On Sep 11, 2013, at 10:52 PM, Dave d...@looktowindward.com wrote: On 11 Sep 2013, at 14:22, Graham Cox graham@bigpond.com wrote: On 11/09/2013, at 3:13 PM, Dave d...@looktowindward.com wrote: Yes, but it doesn't remember the last value of a notification, which is what I would like. [] Yes, I am removing myself as a receiver, but ideally I want to receive these notification even if the object is dead. By this I mean, I want the last known value of the notification restored when the Object in question starts up again. At present I have to save this somewhere ugly and restore it from somewhere ugly. I just thought it would be nice to be able to just make a call something like: -(void) reissueLastNotificationName:@Note1 forClass:self Rather than save it somewhere ugly 26 more times! I could maybe subclass NSNotificationCenter? There are a couple of statements here that don't make a huge amount of sense. What do you mean by an object….starts up again? I mean when the object is created - at this point I want the latest version of the Notification, not the Notification when the Object Died. Perhaps the problem is really that your object should not be being killed until the final notification has been received? That's a different problem. No, there is no final notification, just one when the data associated with it changes. If you mean you want to save something between launches of your app so you can restore state, that's easily done by the sender of the notification. No, I just want the latest version of the notification when the object is created. Yes, I could save it at the sender, but I'd still have the problem of restoring it when the object is created and wants to set itself to the current state. Basically, when it is created I want it to fetch the latest update and apply it to itself data at init time. I don't want to store the old value. Think like this: Object has not been created……….. Send Notification A Send Notification B Send Notification C Send Notification D Send Notification E Object is Created……….. Set Data from Notification E Send Notification F Object is Alive……….. Set Data from Notification F Send Notification G Object is Alive……….. Set Data from Notification G Object is deleted/released. Send Notification H Send Notification I Send Notification J Object is Created……….. Set Data from Notification J Basically, there isn't enough detail in your question to advise, and what you have given appears to smell a bit. Reissuing a notification sounds like a band-aid for a problem that should be solved some other way, to me. Subclassing NSNotificationCenter is presumably possible, but sounds like the wrong way to do whatever it is you are really trying to do. I want the above, I thought subclassing NSNotificationCenter and adding a memory would be quite a neat way of doing it - 27 times. All the Best Dave Sounds like all you really want is to save some state, specifically a notification state. You just ivar/property/object somewhere that keeps track of the last sent Notification. Put it in the most accessible place to each of the observer objects. It could simply be a property class NSNotification and it will have everything it had before. Just keeps a reference. Update the reference as new notifications come. To do that, you also need an object that is the notification nanny/monitor which watches and tracks the most recent one. The nanny/monitor can be both an observer of the same notifications, and either keep a reference to the latest one, or set a reference elsewhere. Should be a simple enough method to add to the instantiation of your object to look to the reference to the last notification and use it for setup. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Slow down a scroller?
On Sep 11, 2013, at 12:49:49, Steve Mills smi...@makemusic.com wrote: On Sep 11, 2013, at 12:16:54, Kyle Sluder k...@ksluder.com wrote: Furthermore, your document view is the same size as your scroll view? Is this intentional? Because that's not how the scrolling architecture is designed to work. Yes, it's very intentional. Like I said, this is a different mode - only part of the document view changes as the user scrolls horizontally. The left edge remains static - it's where the staff names are listed. Well. If I size the document view so it's 2x wider than the scroll view, then scrollwheel events events appear as non-zero and the scrolling actually works as expected. I think this will work. We never actually let the document view's origin change in this mode, because the scroll view is not really scrolling it, and we always respect the clip when drawing, so we won't be drawing too much. Thanks for bouncing ideas around in my brain. :) -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 64-bit iOS
On Wed, Sep 11, 2013 at 12:41 PM, Jean-Daniel Dupas devli...@shadowlab.orgwrote: Thanks for this remainder, but I think we all already know that 620k is enough for anyone… Well, I must confess I didn't know that. I thought 640k was required. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 64-bit iOS
Scott, No, but it's great to device to access data, perhaps even bits pulled out from a huge pile, and preferably pulled out extremely quickly. And, anyway, why shouldn't it be a huge database machine??? I meant, it is not designed to serve as a database machine. I can’t possibly imagine PostGreSQL running on an iPhone, for example, and serving thousand of requests per second… As I said earlier, 64-bit enables techniques that are not practical in 32-bit, because you won't run out of address space due to fragmentation. 64-bit address space might mask fragmentation at the virtual memory level, but you will probably experience it at the real memory level, i.e. after the MMU; the more so, since iOS does not support swapping. How much memory does the iPhone 5S have? More than 4 GiB? Probably not. I fear many people will think that with 64-bit pointers they get a lot of usable space, and then see their code crippled by low memory warnings. Aside from this, I concur it might be handier for Apple to converge all its platforms to 64-bits. Vincent ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: ARC vs Manual Reference Counting
On Wed, Sep 11, 2013 at 6:58 AM, Dave d...@looktowindward.com wrote: On 11 Sep 2013, at 05:04, Jens Alfke j...@mooseyard.com wrote: On Sep 10, 2013, at 12:33 PM, Dave d...@looktowindward.com wrote: You with all this talk of memory management, you'd think that Apple (or someone) would have come up with a hardware solution for this by now. In the 70's and 80's I worked on some firmware and hardware that would handle garbage collection in real time (with a little help from OS Software). I’ve read through a lot of GC papers in the past, and I’m not sure what you’re talking about here, unless it’s something that allows extra tag bits to be stored in pointers. This was used a lot in old LISP systems; it can be useful with interpreted languages but I don’t think it’d be applicable to a C-based language. (A lot of the more sophisticated GC techniques simply don’t work with C-like code because it’s too low-level and makes too many assumptions about memory. For example, you can’t use compaction or copying collectors at all because objects can’t be relocated. The Obj-C garbage collector had to rely on inefficient conservative mark/sweep algorithms.) This was using aUnix Box/MS-DOS box and it was our own hardware, and yes it worked with C and Assembler (via a set of Macro's). Basically it was a lump of hardware that controlled allocating memory from a pool. It wasn't used for system memory (although it could have been), but as a way of speeding up certain Image Processing operations. Basically it could allocate or free a memory block in one machine cycle - it could also copy or fill a block much faster then the CPU too. The world is a very different place than it was then, in the 80s RAM was a lot faster relative to the CPU. There is absolutely no way something like you describe today could be done today, most deeply pipelined OoOE CPUs can barely forward a register in 1 CPU cycle. Getting out to L3 cache is often on the order of 20-40 cycles depending on the part, and main memory can literally be hundreds of cycles. Algorithms designed to work in an environments with single cycle ram access simply don't hold up on modern pipelined cache coherent multi-process systems where the processing logic runs at significant multiples of the memory. If Apple were to implement something like this I think there would be a massive increase in performance and reliability Nothing personal, but I think you’re falling into the common fallacy of thinking that Apple engineers are naive and/or ignorant. It happens all the time on these lists. In general, you should assume that the people working on system software are pretty damn smart and experienced, and are aware of all the techniques that an interested but non-expert outsider would know of. If they’re not using them, there’s probably a good reason for it. I'm sure the engineers are a mixture of good, mediocre, and not so good the same as any where else, why should Apple be different? But engineers don't get much say on what projects/features are implemented (especially somewhere like Apple, MS or any of the big 5 technology companies). If you mean user features then sure, often engineers have little say. If you mean runtime and developer features then you are wrong, the developers at Apple have a lot of say in how what happens. Tim Cook and Phil Schiller didn't sit down in a meeting and say Let's implemented tagged pointers, users will love those, and yet somehow we have them ;-) Louis ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: 64-bit iOS
On 11 Sep, 2013, at 11:01 pm, Vincent Habchi vi...@macports.org wrote: Probably not. I fear many people will think that with 64-bit pointers they get a lot of usable space, and then see their code crippled by low memory warnings. The conversion guide makes a particular point about memory pressure on small devices when code moves to 64 bit. This is definitely going to be something developers have to think about and use the tools to work out where memory is suffering. I think Apple knows this but has gone there anyway. Still standing by my last mail about how this is a good early step towards 64 bit and will eventually be the right move, i think without 2x the memory on-device and with the different memory issues involved in a larger address space, there's going to be some struggling at the start. ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Slow down a scroller?
I didn't get any responses when I sent this a few months ago. How about now? Is there any way to make a scroller less touchy? We have a couple cases where the horizontal scroller isn't controlling pixel movements of the view, but is used for more granular movements (rounded to the beginning of each measure in a musical score). It doesn't take much to flick it from 0 to 1 in this case, and it's impossible to swipe slowly enough to achieve measure-by-measure scrolls. I've tried multiplying the thumb proportion by even large numbers like 100, but it doesn't seem to affect its sensitivity at all. Any ideas? -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: AuthorizationExecuteWithPrivileges deprecated
On 2013 Sep 11, at 08:34, Charles Srstka cocoa...@charlessoft.com wrote: You have to use SMJobBless to install the tool as root, and then pick your favorite form of IPC to communicate with it (XPC is best, if you can require 10.7). That is correct. This example by Steve Streeting will probably help… https://bitbucket.org/sinbad/privilegedhelperexample ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Slow down a scroller?
On Sep 11, 2013, at 11:30:45, Alex Zavatone z...@mac.com wrote: Think about this. When in iTunes on an iOS device, and you are scrubbing an audio track, the farther down your finger is from the scrub knob, when you drag left and right, there is a multiplier to make the scrubbing slower. I'm thinking that in your case, you could use a scroll rate multiplier that changes depending on a measurement that you define. I think that you'd multiply by numbers 1, not use large numbers. My mistake. I should've said that I was dividing by 100. I guess I also neglected to mention that this scroller is the scroller in an NSScrollView. In this mode, the document view is the same size as the scroll view, and we change the scroller's target and action instead of using the default so we can make the scroller pretend it's scrolling measure by measure instead of by pixels. I'm thinking the problem here is that since the doc view is the same size as the scroll view, it doesn't know that it needs to send scrollwheel events in smaller increments, even though the scroller's thumb size is very small. Does that sound feasible? It seems that the scroller doesn't really affect how the scroll view handles scrollwheel events, but it's only there to show where you are within the document view and to handle actual clicks in the scroller's thumb and page area (now that it no longer has those nice arrows that sure were useful before they took them away). -- Steve Mills office: 952-818-3871 home: 952-401-6255 cell: 612-803-6157 ___ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
Re: Slow down a scroller?
On Sep 11, 2013, at 9:59 AM, Steve Mills smi...@makemusic.com wrote:
My mistake. I should've said that I was dividing by 100. I guess I also
neglected to mention that this scroller is the scroller in an NSScrollView.
In this mode, the document view is the same size as the scroll view, and we
change the scroller's target and action instead of using the default so we
can make the scroller pretend it's scrolling measure by measure instead of by
pixels.
Does calling -[NSScrolView set{Vertical,Horizontal}LineScroll:] not affect the
scroll wheel behavior?
If not, what about implementing -scrollWheel: in your document view?
Furthermore, your document view is the same size as your scroll view? Is this
intentional? Because that's not how the scrolling architecture is designed to
work.
--Kyle Sluder
___
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
