Go to sleep guys. Sent from my iPhone
On Nov 8, 2011, at 11:53 PM, cocoa-dev-requ...@lists.apple.com wrote: > Send Cocoa-dev mailing list submissions to > cocoa-dev@lists.apple.com > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.apple.com/mailman/listinfo/cocoa-dev > or, via email, send a message with subject or body 'help' to > cocoa-dev-requ...@lists.apple.com > > You can reach the person managing the list at > cocoa-dev-ow...@lists.apple.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Cocoa-dev digest..." > > > Today's Topics: > > 1. Re: Detect Siri (John Joyce) > 2. Re: ObjC's flat and all-exported namespace, help! (John Joyce) > 3. Re: NSFileHandle readInBackground vs threading? > (Alexander Bokovikov) > 4. Re: NSFileHandle readInBackground vs threading? (Scott Ribe) > 5. Re: Allocating too much memory kills my App rather than > returning NULL (Don Quixote de la Mancha) > 6. Re: Allocating too much memory kills my App rather than > returning NULL (Wade Tregaskis) > 7. Re: ObjC's flat and all-exported namespace, help! (Karl Goiser) > 8. Re: Allocating too much memory kills my App rather than > returning NULL (Conrad Shultz) > 9. Re: Allocating too much memory kills my App rather than > returning NULL (Don Quixote de la Mancha) > 10. Re: NSFileHandle readInBackground vs threading? (Kyle Sluder) > 11. Re: Allocating too much memory kills my App rather than > returning NULL (Graham Cox) > 12. Re: Allocating too much memory kills my App rather than > returning NULL (Don Quixote de la Mancha) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 09 Nov 2011 13:24:32 +0900 > From: John Joyce <dangerwillrobinsondan...@gmail.com> > Subject: Re: Detect Siri > To: Manfred Schwind <li...@mani.de> > Cc: Cocoa-Dev Mailing List <cocoa-dev@lists.apple.com> > Message-ID: <d4394a71-9b91-46ee-86d2-4b28c5694...@gmail.com> > Content-Type: text/plain; charset=us-ascii > > Have you asked Siri? > > On Nov 9, 2011, at 12:08 AM, Manfred Schwind wrote: > >> Hi, >> >> is there a way to find out if the current device generally supports Siri? >> I'm not interested if it's currently turned on or off. I just want to know >> if it is generally possible to use Siri on the current device. >> >> I could specifically check for iPhone 4S, but I think that's a bad idea, >> because other devices will most probably support Siri in the future, too. >> >> Mani >> -- >> http://mani.de - friendly software >> >> _______________________________________________ > > > > ------------------------------ > > Message: 2 > Date: Wed, 09 Nov 2011 13:39:04 +0900 > From: John Joyce <dangerwillrobinsondan...@gmail.com> > Subject: Re: ObjC's flat and all-exported namespace, help! > To: undisclosed-recipients: ; > Cc: cocoa-dev List <cocoa-dev@lists.apple.com> > Message-ID: <8e71de7c-fb44-4e48-b67a-4684f0b44...@gmail.com> > Content-Type: text/plain; charset=iso-8859-1 > > This should be on the Obj-C list. > This whole discussion is about the language implementation. > The Obj-C list needs more love anyway. > > On Nov 9, 2011, at 10:30 AM, Jean-Daniel Dupas wrote: > >> >> Le 9 nov. 2011 � 01:37, Ian Joyner a �crit : >> >>> On 9 Nov 2011, at 05:21, Greg Parker wrote: >>> >>>> On Nov 8, 2011, at 9:57 AM, Andy O'Meara wrote: >>>>> Yes, I know that one workaround is to mangle all objC class names based >>>>> on something unique in the project (we are forced to do this with our >>>>> screensaver products). I'd be more accepting of this if Xcode >>>>> facilitated this (with perhaps a macro of or the introduction of >>>>> @privateinterface or something), but I don't fancy the idea of having to >>>>> stick nasty and limiting #includes, #defines, or #ifdefs all over our >>>>> code to make sure stuff compiles and links correctly just to workaround >>>>> the fact that objC seems like it should really allow classes to not be >>>>> exported by default into a single/shared namespace. >>>> >>>> This is the only solution. >>>> >>>> >>>>> I suppose if there's no solution to this, then someone is going to >>>>> describe how it can't be done because it would somehow break the loading >>>>> of bundles. Well if that's the case, then I'm thinking that a radar is >>>>> still worth filing because I'd be pretty surprised if the senior >>>>> engineering level is going to agree that this whole flat objC namespace >>>>> business is consistent with the precept that software should 'just work', >>>>> rather than 'usually work' and emit user-attention-getting log messages >>>>> as long as two internally private class names don't happen to have the >>>>> same name. >>>> >>>> >>>> <rdar://problem/2821039> ER: Objective-C namespaces >>>> >>>> If you're familiar with Radar numbers, you'll recognize that the bug is >>>> very old. The name is a bit misleading - C++ namespaces or Java packages >>>> are little better than adding name prefixes by hand. (For example, they >>>> don't solve the problem of two developers importing the same static >>>> archive.) A real solution for class name collisions needs to be (1) >>>> automatic or nearly so, (2) predictable so nib references work, and (3) >>>> not incompatible with existing classes. It's a hard problem. >>> >>> I agree, in NS::class, just substitute the ugly :: with _ and you see it's >>> just a trick: NS_class. There should be a decent solution that doesn't need >>> to put extra bookkeeping constructs in the language, and so that the clash >>> is avoided in one place. Another point is that code in a class should not >>> be bound to the environment and the C++ and Java way of doing it says >>> 'environment' all over the place. >>> >>> A different approach is in Eiffel that identifies the problem as being when >>> you try to use two libraries together and handles clashes in one place by >>> renaming (in a configuration file separate from code). Thus it becomes a >>> linker concern. >> >> Objective-C uses a dynamic runtime. The linkers (both the static one and the >> dynamic one) cannot take care of all possible cases. >> How do you handle NSClassFromString used with a non constant string ? >> >>> Language design should keep compilation concerns separate from linking >>> concerns (and indeed not just static linking, but dynamic run-time >>> linking). On the other hand most Unix style C linkers really don't do >>> enough to make sure things can be sensibly linked together, so the basic >>> languages and compilers get bent instead and then programmers are forced to >>> think of all these things at a lower level than they should need to. >>> >>> Similarly, imports and #includes are really bad, because they couple >>> modules to their environment, rather than this kind of linkage being done >>> externally in one place and handled by the linker. This means that if any >>> import changes, you have to go through all the files and change all the >>> imports and it looks like you are programming, but really you are not. So >>> we invent a refactoring to take care of something that shouldn't exist. >>> >>> Anyway, that's my argument for not doing namespaces in Objective-C the Java >>> or C++ way. There's not so much clutter in Java, but there is so much >>> clutter in C++ it looks like Windows! I'm sure Apple will come up with a >>> better solution and things they have done over the last few years with >>> Objective-C (and tagged pointers in Lion as we have just discussed in the >>> Obj-C group) have been very nice and simplifying (even for a language based >>> on C). We should not force them into doing anything the same bad old way >>> that everything else does. >> >> -- Jean-Daniel > > > ------------------------------ > > Message: 3 > Date: Wed, 09 Nov 2011 11:02:51 +0600 > From: Alexander Bokovikov <openwo...@uralweb.ru> > Subject: Re: NSFileHandle readInBackground vs threading? > To: Scott Ribe <scott_r...@elevated-dev.com> > Cc: cocoa-dev@lists.apple.com > Message-ID: <63156a88-119a-4c0a-a129-0d557ce21...@uralweb.ru> > Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes > > > On 09.11.2011, at 0:50, Scott Ribe wrote: > >> On Nov 8, 2011, at 9:54 AM, Alexander Bokovikov wrote: >> >>> I have a need to read some data from a local socket, which serves >>> for IPC. And data may come very quickly, so (AFAIU) inner socket >>> buffer might overflow, so a portion of data might be lost. >> >> What makes you think that? If the buffers fill up, writes will block. > > OK, then the same problem will appear at the other end of the socket. > One way or another I need to read from the socket as fast as possible. > And I have a real problem now. Sometimes data are lost when they come > with high speed. Though I agree, that first I need to investigate what > end of the socket has a bottle neck. > > Thank you. > > > ------------------------------ > > Message: 4 > Date: Tue, 08 Nov 2011 22:43:14 -0700 > From: Scott Ribe <scott_r...@elevated-dev.com> > Subject: Re: NSFileHandle readInBackground vs threading? > To: Alexander Bokovikov <openwo...@uralweb.ru> > Cc: cocoa-dev@lists.apple.com > Message-ID: <0c530fa6-b4c0-4b26-859c-45ce2e72a...@elevated-dev.com> > Content-Type: text/plain; charset=us-ascii > > On Nov 8, 2011, at 10:02 PM, Alexander Bokovikov wrote: > >> Sometimes data are lost when they come with high speed. > > I assume by "local socket" you mean either a UNIX domain socket or just a > regular TCP socket on the local machine? If so, just using regular read & > write calls there's no way for data to be lost & not delivered just because > it's consumed slowly. There's something else going on. Either the sending end > is discarding data and not even writing it, or the receiving is losing it > after reading it. > > -- > Scott Ribe > scott_r...@elevated-dev.com > http://www.elevated-dev.com/ > (303) 722-0567 voice > > > > > > > ------------------------------ > > Message: 5 > Date: Tue, 08 Nov 2011 21:43:30 -0800 > From: Don Quixote de la Mancha <quix...@dulcineatech.com> > Subject: Re: Allocating too much memory kills my App rather than > returning NULL > To: Joar Wingfors <j...@joar.com> > Cc: Cocoa-Dev List <cocoa-dev@lists.apple.com> > Message-ID: > <cagl4zzem4vji1msspotfwpw9uc2mqd9tixhursyi4xcpjqw...@mail.gmail.com> > Content-Type: text/plain; charset=ISO-8859-1 > > I just filed a bug report that includes a minimal test case, in which > all the calls to calloc() are made from within main(). There are no > calls of any sort to Objective-C methods or any use of Cocoa Touch > classes. > > rdar://10417644 > > I don't REALLY need to exhaust my App's memory space. What I really > need to do is find out how much memory I can safely allocate. I would > have expected to do that by allocating as much memory as the user asks > for, then backing out gracefully if any of the allocations failed. > > It would be enough if there were some way I could check ahead of time > how much I can safely allocate, without actually trying to allocate > it. Is there an API for that? > > My App seems to be getting killed without any UNIX signals being > delivered to it. GDB is unaware that the process has terminated after > it has been killed. > > As I said before the Simulator does the right thing. In the > Simulator, I get these messages in GDB: > > No_Cocoa_Touch(1834) malloc: *** mmap(size=16777216) failed (error code=12) > *** error: can't allocate region > *** set a breakpoint in malloc_error_break to debug > > I can set a breakpoint in malloc_error_break when I run on a device, > but that breakpoint is never hit. > > A bad workaround would be to just empirically determine how much > memory is safe to allocate by trying various grid sizes. A binary > search would determine that pretty quickly for each of my devices. > But that is not the desired solution, because future hardware models > will likely have more physical RAM. Also the amount that can be > safely allocated would depend on how much is left over from other > processes, and so could not be counted upon to be any particular fixed > amount. > > -- > Don Quixote de la Mancha > Dulcinea Technologies Corporation > Software of Elegance and Beauty > http://www.dulcineatech.com > quix...@dulcineatech.com > > > ------------------------------ > > Message: 6 > Date: Tue, 08 Nov 2011 21:48:13 -0800 > From: Wade Tregaskis <wadesli...@mac.com> > Subject: Re: Allocating too much memory kills my App rather than > returning NULL > To: Joar Wingfors <j...@joar.com> > Cc: Cocoa-Dev List <cocoa-dev@lists.apple.com> > Message-ID: <62ab275a-9ecf-4fe8-ab12-bd56beb81...@mac.com> > Content-Type: text/plain; CHARSET=US-ASCII > >> Simple as that, eh? Being able to gracefully handle all out of memory >> situations to me seems as "simple" as being required to treat every single >> method / function call as potentially raising an exception, and requiring >> the developer to add handlers + cleanup code. No existing code (OS or apps) >> is exceptions safe at every single line of source code. At the very least >> this would require a complete rewrite / review of every single line of >> existing source code in both OS and apps, something that seems neither >> simple nor practical to me. > > Another straw man. We could, hypothetically, talk about the probabilities, > but neither of us has sufficient data. Like most things in software > development, it's up to each individual to decide where the balance is > between defensive coding and whatever trade-offs it requires. My aim here > has been to persuade anyone listening that this is something they have a > meaningful influence over. I hope for my own selfish sake that I've > succeeded at least a little, just in case I end up using code written by any > of our listeners. > > > ------------------------------ > > Message: 7 > Date: Wed, 09 Nov 2011 17:08:57 +1100 > From: Karl Goiser <li...@goiser.com> > Subject: Re: ObjC's flat and all-exported namespace, help! > To: cocoa-dev List <cocoa-dev@lists.apple.com> > Message-ID: <d3d29d36-cdcc-4557-8a79-dc9bd1c83...@goiser.com> > Content-Type: text/plain; charset=windows-1252 > > I think there is another solution that doesn�t involve making the language > more complicated: > > I would complain to the suppliers of the bundles with conflicting class names. > > They know they are delivering into an environment with a flat namespace. It > is up to them to defend against this sort of problem. It�s their fault that > this problem is occurring. > > > Karl > > > > ------------------------------ > > Message: 8 > Date: Tue, 08 Nov 2011 22:39:24 -0800 > From: Conrad Shultz <con...@synthetiqsolutions.com> > Subject: Re: Allocating too much memory kills my App rather than > returning NULL > To: Don Quixote de la Mancha <quix...@dulcineatech.com> > Cc: Cocoa-Dev List <cocoa-dev@lists.apple.com>, Joar Wingfors > <j...@joar.com> > Message-ID: <4eba201c.9000...@synthetiqsolutions.com> > Content-Type: text/plain; charset=ISO-8859-1 > > On 11/8/11 9:43 PM, Don Quixote de la Mancha wrote: >> It would be enough if there were some way I could check ahead of time >> how much I can safely allocate, without actually trying to allocate >> it. Is there an API for that? > > I don't see how there COULD be an API for that for the simple reason > that the phone is not a static device, and your app does not run in a > vacuum. Phone calls can come in, alerts can fire, background processes > can run. At best you have a race condition. > > This seems very much like the "how do I check for server availability?" > question that comes up on the list every couple months, with the > inevitable response of "try it." > >> A bad workaround would be to just empirically determine how much >> memory is safe to allocate by trying various grid sizes. A binary >> search would determine that pretty quickly for each of my devices. >> But that is not the desired solution, because future hardware models >> will likely have more physical RAM. Also the amount that can be >> safely allocated would depend on how much is left over from other >> processes, and so could not be counted upon to be any particular fixed >> amount. > > And there's a bigger problem. That memory warning notification that you > referenced in your first message is there to tell you that you need to > free up resources ASAP at run-time. Quoting from the iOS App > Programming Guide: > > "Using large amounts of memory can seriously degrade system performance > and potentially cause the system to terminate your app." > > You don't just get to hold onto whatever memory the OS can allocate at > some arbitrary point in your app's life cycle. iOS will keep system > services (from telephony on down) running at all costs, and (AFAICT) > will keep Apple-supplied background tasks running as well (e.g. > i _______________________________________________ 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
