On 3 Mar 2014, at 5:09 pm, Graham Cox wrote:
> Since I suspect some sort of memory overflow to be causing the problem, I did
> attempt to use the usual tools for this - guard malloc, scribbling, etc, but
> nothing showed up. Once again the opaque nature of a framework class makes
> tracking
I have a MyOperation, subclass of NSOperation.
MyOperation does:
create an NSOperationQueue
add a few MyOperations to this queue
waitUntilAllOperationsAreFinished
(obviously this recursion stops at some point - I do not create an infinite
number of operations).
The good
On Mar 2, 2014, at 23:58 , Graham Cox wrote:
> the more general question here is whether returning nil from -initWithCoder:
> should be legitimate or not. After all, it's an init method, and it should
> follow the rules for all other init methods, shouldn't it?
What are you suggesting that the
If you do end up writing your own safe-saving logic, that's achieved by
overriding -writeSafelyToURL:…
Sent from my iPad
On 2 Mar 2014, at 15:23, Trygve Inda wrote:
>> 7,500 file operations of any kind are going to take some time, even just
>> creating hard links. Does it require 40 seconds? W
On 3 Mar 2014, at 7:48 pm, Quincey Morris
wrote:
> What are you suggesting that these rules are? AFAIK, there isn’t any “rule”
> about whether an init method can return nil — it’s part of the API contract
> in each individual case, isn’t it?
The documentation for -init states:
"If the new
On 3 Mar 2014, at 09:47, Graham Cox wrote:
>
>
>> IAC, I don’t think it’s exactly about whether initWithCoder returns nil.
>> Surely it’s about the fact that decoding a NSArray can’t deal with a nil
>> element, since it can’t be inserted into the array. Simply dropping nil
>> elements doesn
On 3 Mar 2014, at 9:56 pm, jonat...@mugginsoft.com wrote:
> It is hard to argue with the statement that you must return self from
> initWithCoder:.
Well, except what is self? It's perfectly legitimate in an init method to write
self = . ***that's why you always check if( self ){} after
c
Hi,
On 3 Mar 2014, at 09:43, Gerriet M. Denkmann wrote:
> I have a MyOperation, subclass of NSOperation.
>
> MyOperation does:
> create an NSOperationQueue
> add a few MyOperations to this queue
> waitUntilAllOperationsAreFinished
> (obviously this recursion stops at some poi
I am pondering the following framework public API method signatures.
The API requires a mixture of const char* and NSString * parameters.
The question is whether to precede const char * parameter names with UTF8 e.g.:
+ (MonoClass *)monoClassWithName:(char *)className fromAssemblyName:(const cha
I would say that adding UTF8 to the method names implies that the framework
expects UTF8, if that's true, that's a good method name.
If you want to support other encodings then a method name which takes a char*
and an encoding would be better, still including a UTF8 version which just
calls th
First, why not have just the NSString versions?
Are you working in an environment where Foundation might not/will not be
linked? Are these selectors bound to library functions that must take char *’s
and you can’t afford the overhead of a second method dispatch or function call
(bearing in min
Forgot to add, if your framework *does* expect and will continue to expect UTF8
strings, then yes, “UTF8Name” is a fine choice.
Daniel
On Mar 3, 2014, at 4:19 PM, Daniel DeCovnick wrote:
> First, why not have just the NSString versions?
>
> Are you working in an environment where Foundation
On 3 Mar 2014, at 15:19, Daniel DeCovnick wrote:
> But, assuming for the moment that you have a really good reason for such a
> Cocoa-unfriendly API:
>
> “UTF8Name" is highly specific. I’d first consider what your source encoding
> is (both of the strings that are likely to be passed to this
On Mar 3, 2014, at 12:43 AM, Gerriet M. Denkmann wrote:
> MyOperation does:
> create an NSOperationQueue
> add a few MyOperations to this queue
> waitUntilAllOperationsAreFinished
> (obviously this recursion stops at some point - I do not create an infinite
> number of operat
On Mar 3, 2014, at 7:19 AM, Daniel DeCovnick wrote:
> Are these selectors bound to library functions that must take char *’s and
> you can’t afford the overhead of a second method dispatch or function call
The OP is working with Mono, a C# runtime, so I’m sure the glue to it takes C
strings.
On 3 Mar 2014, at 23:14, Jens Alfke wrote:
>
> On Mar 3, 2014, at 12:43 AM, Gerriet M. Denkmann wrote:
>
>> MyOperation does:
>> create an NSOperationQueue
>> add a few MyOperations to this queue
>> waitUntilAllOperationsAreFinished
>> (obviously this recursion stops at some p
Sure, but the consumer of the framework is still an Objective-C application or
framework, which is going to be using NSStrings for everything else already and
presumably up to the boundary with this framework. Why make the consumer do the
conversion? If the method is going to be called “a lot”,
On 03 Mar 2014, at 17:09, jonat...@mugginsoft.com wrote:
> Commonly the char *strings represent a C# identifier
> http://msdn.microsoft.com/en-us/library/aa664670.aspx
I can't answer this for you, but should it even be exposed in the API that it
is a string? Think of SEL. Under the hood, it is
On Mar 3, 2014, at 5:09 PM, jonat...@mugginsoft.com wrote:
>
> Hmm.That’s a good point. I was hung up on the Cocoa side of things.
>
> Commonly the char *strings represent a C# identifier
> http://msdn.microsoft.com/en-us/library/aa664670.aspx
> The rules for identifiers given in this section
On Mar 3, 2014, at 01:47 , Graham Cox wrote:
> On 3 Mar 2014, at 7:48 pm, Quincey Morris
> wrote:
>
>> IAC, I don’t think it’s exactly about whether initWithCoder returns nil.
>> Surely it’s about the fact that decoding a NSArray can’t deal with a nil
>> element, since it can’t be inserted i
On Mon, Mar 3, 2014, at 09:54 AM, Daniel DeCovnick wrote:
> Given that, UTF8Name actually sounds fine.
No it doesn't. There's nothing in Jonathan's links to suggest that the
CLS specifies that identifiers are stored in UTF-8 encoding. In fact, it
implies otherwise:
"""Before you compare identifi
On 3 Mar 2014, at 19:23, Kyle Sluder wrote:
> But Jonathan, why are you even exposing raw C pointer access to the
> identifiers in the first place? Why wouldn't you convert them to
> NSStrings and only expose them to Objective-C code that way?
>
Jens sort of nailed it.
The underlying Mono API i
On Thu, 27 Feb 2014 07:19:26 +0800, Roland King said:
>Is there an NSNotification or some other kind of notification you can
>subscribe to when there's a change in /dev? I'm dealing with an old USB-
>serial device which creates a cu/tty when inserted (and removed when
>removed) and I'd like to ge
>
I did some testing about optimal number
> of files per folder for our package
format and 3750 files per directory are
> way too many. The file system is much
more efficient if you spread those
> files into sub-folders. We got the best performance with a 3-level sparse
> folder index (files are
On 4 Mar 2014, at 5:30 am, Quincey Morris
wrote:
> t can certainly be true that for some unarchived arrays, dropping
> un-unarchivable elements is appropriate. You’re currently dealing with such a
> case. That’s a valid strategy for your app, but it’s not a valid strategy for
> the framework
On Mar 3, 2014, at 14:26 , Trygve Inda wrote:
> I did some testing
>
> All 3750 in one folder: 40 seconds to save.
>
> Split into two levels: 16 folders -> 16 folders -> image files: 5 sec
>
> Three levels: 16 folders -> 16 folders -> 16 folders -> image files: 10 sec
It seems to me this
On Mar 3, 2014, at 14:42 , Graham Cox wrote:
> If NSKeyedUnarchiver was doing this, I'd have discovered my bug immediately,
> instead of taking three very hard and wearisome days to track it down.
Yes. In fact, there are at least three bugs worth reporting:
1. Inadequate documentation of the r
27 matches
Mail list logo
