Re: Cocoa-dev Digest, Vol 8, Issue 888
Re: Cocoa-dev Digest, Vol 8, Issue 888
- Subject: Re: Cocoa-dev Digest, Vol 8, Issue 888
- From: Craig Brewer <email@hidden>
- Date: Wed, 09 Nov 2011 00:14:28 -0700
Go to sleep guys.
Sent from my iPhone
On Nov 8, 2011, at 11:53 PM, email@hidden wrote:
> Send Cocoa-dev mailing list submissions to
> email@hidden
>
> 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
> email@hidden
>
> You can reach the person managing the list at
> email@hidden
>
> 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 <email@hidden>
> Subject: Re: Detect Siri
> To: Manfred Schwind <email@hidden>
> Cc: Cocoa-Dev Mailing List <email@hidden>
> Message-ID: <email@hidden>
> 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 <email@hidden>
> Subject: Re: ObjC's flat and all-exported namespace, help!
> To: undisclosed-recipients: ;
> Cc: cocoa-dev List <email@hidden>
> Message-ID: <email@hidden>
> 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 <email@hidden>
> Subject: Re: NSFileHandle readInBackground vs threading?
> To: Scott Ribe <email@hidden>
> Cc: email@hidden
> Message-ID: <email@hidden>
> 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 <email@hidden>
> Subject: Re: NSFileHandle readInBackground vs threading?
> To: Alexander Bokovikov <email@hidden>
> Cc: email@hidden
> Message-ID: <email@hidden>
> 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
> email@hidden
> 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 <email@hidden>
> Subject: Re: Allocating too much memory kills my App rather than
> returning NULL
> To: Joar Wingfors <email@hidden>
> Cc: Cocoa-Dev List <email@hidden>
> Message-ID:
> <email@hidden>
> 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
> email@hidden
>
>
> ------------------------------
>
> Message: 6
> Date: Tue, 08 Nov 2011 21:48:13 -0800
> From: Wade Tregaskis <email@hidden>
> Subject: Re: Allocating too much memory kills my App rather than
> returning NULL
> To: Joar Wingfors <email@hidden>
> Cc: Cocoa-Dev List <email@hidden>
> Message-ID: <email@hidden>
> 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 <email@hidden>
> Subject: Re: ObjC's flat and all-exported namespace, help!
> To: cocoa-dev List <email@hidden>
> Message-ID: <email@hidden>
> 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 <email@hidden>
> Subject: Re: Allocating too much memory kills my App rather than
> returning NULL
> To: Don Quixote de la Mancha <email@hidden>
> Cc: Cocoa-Dev List <email@hidden>, Joar Wingfors
> <email@hidden>
> Message-ID: <email@hidden>
> 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 (email@hidden)
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:
This email sent to email@hidden