Hi all,
I am pulling my hair out here trying to replace the unicode (r) symbol with
\\00ea in a string. Is there a way of doing this as the NSString is a unicode
String so it is interpreting it. As convenient that might be to most people it
is killing me here.
Any suggestions?
Damien
Thirded. I thought I wouldn't like it. As soon as I didn't have to manage
retains and releases of temporary objects, the discipline completely left my
mind. Now whenever I go back to non-ARC code I invariably make a ton of memory
management errors, most of which are caught by the analyzer.
--Ky
On 9 Sep 2013, at 09:13, Damien Cooke wrote:
> Hi all,
> I am pulling my hair out here trying to replace the unicode (r) symbol with
> \\00ea in a string. Is there a way of doing this as the NSString is a
> unicode String so it is interpreting it. As convenient that might be to most
> peopl
On 9 Sep 2013, at 09:44, Kyle Sluder wrote:
> Thirded. I thought I wouldn't like it. As soon as I didn't have to manage
> retains and releases of temporary objects, the discipline completely left my
> mind. Now whenever I go back to non-ARC code I invariably make a ton of
> memory management
Le 9 sept. 2013 à 09:54, Tom Davie a écrit :
>
> On 9 Sep 2013, at 09:13, Damien Cooke wrote:
>
>> Hi all,
>> I am pulling my hair out here trying to replace the unicode (r) symbol with
>> \\00ea in a string. Is there a way of doing this as the NSString is a
>> unicode String so it is inte
Le 9 sept. 2013 à 09:58, Tom Davie a écrit :
>
> On 9 Sep 2013, at 09:44, Kyle Sluder wrote:
>
>> Thirded. I thought I wouldn't like it. As soon as I didn't have to manage
>> retains and releases of temporary objects, the discipline completely left my
>> mind. Now whenever I go back to non-
As someone who considered garbage collection and decided against it and stayed
with manual retain and release at that time. I got along reasonably well with
manual retain and release. I have happily moved to ARC for a new project. I
spent at least a few days getting my head wrapped around the us
It's something new to learn, but in order to stay current there will always be
something new. I'm just porting my software to ARC, and whilst there are one
or two gotchas (oversights on my part, leading to leakage), I'm finding it to
be an excellent idea. Using ARC (in my experience) leads to
On Sep 9, 2013, at 9:44 , Kyle Sluder wrote:
> Thirded.
Countered. :-)
> I thought I wouldn't like it.
I thought I would LOVE it, and when I actually used it was “meh”. Not just the
additional rules/complexity when dealing with the C side of things (which I do
quite a bit), but more import
On 09/09/2013, at 10:49 AM, Marcel Weiher wrote:
> I thought I would LOVE it, and when I actually used it was “meh”. Not just
> the additional rules/complexity when dealing with the C side of things (which
> I do quite a bit), but more importantly it just didn’t make any difference on
> the
On 9 Sep 2013, at 10:18, Jean-Daniel Dupas wrote:
>
> Le 9 sept. 2013 à 09:58, Tom Davie a écrit :
>
>>
>> On 9 Sep 2013, at 09:44, Kyle Sluder wrote:
>>
>>> Thirded. I thought I wouldn't like it. As soon as I didn't have to manage
>>> retains and releases of temporary objects, the discip
Le 9 sept. 2013 à 11:33, Tom Davie a écrit :
>
> On 9 Sep 2013, at 10:18, Jean-Daniel Dupas wrote:
>
>>
>> Le 9 sept. 2013 à 09:58, Tom Davie a écrit :
>>
>>>
>>> On 9 Sep 2013, at 09:44, Kyle Sluder wrote:
>>>
Thirded. I thought I wouldn't like it. As soon as I didn't have to mana
On 9 Sep 2013, at 11:49, Jean-Daniel Dupas wrote:
>
> Le 9 sept. 2013 à 11:33, Tom Davie a écrit :
>
>>
>> On 9 Sep 2013, at 10:18, Jean-Daniel Dupas wrote:
>>
>>>
>>> Le 9 sept. 2013 à 09:58, Tom Davie a écrit :
>>>
On 9 Sep 2013, at 09:44, Kyle Sluder wrote:
> Th
On Sep 9, 2013, at 1:43 AM, Patrick Cusack wrote:
> Apologies. I have no desire to start an internecine war. I have been reading
> up on ARC for the past few hours. I also watched the WWDC video on ARC, and
> after having watched and read everything, I kept feeling as if I was rather
> comfort
On 9 Sep 2013, at 10:33, Tom Davie wrote:
>
> Yes, it does. If you’d like an example to verify this behaviour with, play
> with converting https://github.com/beelsebob/CoreParse to ARC, and profiling
> the result. This is the example that showed 100% slowdown initially. The
> last time I t
On Sep 9, 2013, at 11:33 , Tom Davie wrote:
>> On 9 Sep 2013, at 10:18, Jean-Daniel Dupas wrote:
>>
>> And does the profiler explicitly shows that ARC runtime code is the culprit
>> ?
>
> Yes, it does.
Isn’t it strange how when someone says “oh, and ARC is faster”, without
measurements, t
On Sep 3, 2013, at 16:54 , Fritz Anderson wrote:
> On 2 Sep 2013, at 12:47 AM, Marcel Weiher wrote:
>
>> This gets (mis-)quoted out of context way too much (my emphasis):
>>
>> "We should forget about small efficiencies, say about 97% of the time:
>> premature optimization is the root o
When performance testing ARC code, remember to test in a release configuration,
with compiler optimisations on. In my experience, it can really make a big
difference; a lot of 'spurious' retain/release pairs are optimised away, and
many objects are released earlier.
Jamie.
On 9 Sep 2013, at 11
Le 9 sept. 2013 à 11:54, Tom Davie a écrit :
>
> On 9 Sep 2013, at 11:49, Jean-Daniel Dupas wrote:
>
>>
>> Le 9 sept. 2013 à 11:33, Tom Davie a écrit :
>>
>>>
>>> On 9 Sep 2013, at 10:18, Jean-Daniel Dupas wrote:
>>>
Le 9 sept. 2013 à 09:58, Tom Davie a écrit :
>
On Sep 9, 2013, at 3:58 AM, Tom Davie wrote:
>
> On 9 Sep 2013, at 09:44, Kyle Sluder wrote:
>
>> Thirded. I thought I wouldn't like it. As soon as I didn't have to manage
>> retains and releases of temporary objects, the discipline completely left my
>> mind. Now whenever I go back to non-A
On Sep 9, 2013, at 12:13 AM, Damien Cooke wrote:
> I am pulling my hair out here trying to replace the unicode (r) symbol with
> \\00ea in a string. Is there a way of doing this as the NSString is a
> unicode String so it is interpreting it. As convenient that might be to most
> people it i
Parsing dates from strings can be surprisingly expensive — more than once I’ve
seen it show up as the primary hot-spot in code that reads files or parses
network data. NSDateFormatter is very flexible, but you pay for that in speed.
If you only need to parse a single simple date/time format you
This may not be that useful in all circumstances - I always send dates as
milliseconds since the UNIX epoch as 64-bit signed integers. Those are *way*
faster to parse.
On Sep 10, 2013, at 0:11, Jens Alfke wrote:
> Parsing dates from strings can be surprisingly expensive — more than once
> I’ve
Le 9 sept. 2013 à 18:11, Jens Alfke a écrit :
> Parsing dates from strings can be surprisingly expensive — more than once
> I’ve seen it show up as the primary hot-spot in code that reads files or
> parses network data. NSDateFormatter is very flexible, but you pay for that
> in speed. If you
Hi Jens,
Premature optimization is the root of all evil!
Er, I misspelled: “very cool, nice job!”
On Sep 9, 2013, at 18:11 , Jens Alfke wrote:
> [..]
> [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took 26.97 µsec
> [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDate
On Sep 9, 2013, at 19:05 , Jean-Daniel Dupas wrote:
>
> Le 9 sept. 2013 à 18:11, Jens Alfke a écrit :
>
>> [fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took 26.97
>> µsec
>> [fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook 0.47
>> µsec (58x)
>
> Isn't
Exactly right.
And you can use the simplex behavior to your advantage. For example that's how
you can build a "fitting size" method (or in other words this is how the system
fitting size method works). Add a constraint with constant 0 with a lower
priority and the system will crush the view as
On Sep 9, 2013, at 19:20 , Tito Ciuro wrote:
>> On Sep 9, 2013, at 10:14 AM, Marcel Weiher wrote:
>> Premature optimization is the root of all evil!
> What's premature about it?
Nothing:
>> Er, I misspelled: “very cool, nice job!”
:-)
Marcel
_
What's premature about it?
-- Tito
> On Sep 9, 2013, at 10:14 AM, Marcel Weiher wrote:
>
> Hi Jens,
>
> Premature optimization is the root of all evil!
>
> Er, I misspelled: “very cool, nice job!”
>
>> On Sep 9, 2013, at 18:11 , Jens Alfke wrote:
>>
>> [..]
>> [fg160,160,160;16:34:40.48
On Sep 9, 2013, at 19:35 , Jens Alfke wrote:
>
> On Sep 9, 2013, at 10:14 AM, Marcel Weiher wrote:
>
>> Premature optimization is the root of all evil!
>
> I’m not sure if you meant that ironically, but it’s absolutely not premature.
Absolutely! On both counts. It just seems to be the app
On 09/09/2013, at 9:56 PM, Trygve Inda wrote:
> am considering merging them into one app, but it would have to be 32bit
> only (though of course it will run on 64bit systems).
>
> Is there any real drawback to this? I'd like to support 10.6 - 10.9 and I
> know that if I merge them into one app
>
> On 09/09/2013, at 9:56 PM, Trygve Inda wrote:
>
>> am considering merging them into one app, but it would have to be 32bit
>> only (though of course it will run on 64bit systems).
>>
>> Is there any real drawback to this? I'd like to support 10.6 - 10.9 and I
>> know that if I merge them i
On Sep 9, 2013, at 10:14 AM, Marcel Weiher wrote:
> Premature optimization is the root of all evil!
I’m not sure if you meant that ironically, but it’s absolutely not premature.
I’ve run into major NSDateFormatter bottlenecks — as in “hm, over half the time
to open this file is spent inside N
On Sep 9, 2013, at 11:35 AM, Jens Alfke wrote:
> I’m not sure if you meant that ironically, but it’s absolutely not premature.
> I’ve run into major NSDateFormatter bottlenecks — as in “hm, over half the
> time to open this file is spent inside NSDateFormatter” — at least twice, and
> the auth
On Sep 9, 2013, at 10:48 AM, Jeffrey Oleander wrote:
> The issue is users entering dates […] am sorely wishing I could just enforce
> ISO date entry as in the quoted example by using pop-up menus. Some do, but
> the dread of customer rebellion is strong, and they want to enter them in the
>
On Sep 9, 2013, at 09:25 , Maxthon Chan wrote:
> This may not be that useful in all circumstances - I always send dates as
> milliseconds since the UNIX epoch as 64-bit signed integers. Those are *way*
> faster to parse.
Yes. It's ridiculous that a lot of JSON APIs send ISO 8601-formatted (or
Just to add a tiny wrinkle:
On Sep 9, 2013, at 20:27 , Jens Alfke wrote:
> On Sep 9, 2013, at 10:48 AM, Jeffrey Oleander wrote:
>> [..] Some do, but the dread of customer rebellion is strong, and they want
>> to enter them in the slap-dash, hurried, harried ways they're used to
>> writing them
I appreciate everyone's replies. It was a question asked in complete humility.
I agree that computers can do analysis much better than humans and that the
less code you write, the less you have to debug, so ARC makes a lot of sense.
My question really stemmed from Apple's WWDC lecture which appe
On 9 Sep 2013, at 20:29, Rick Mann wrote:
>
> On Sep 9, 2013, at 09:25 , Maxthon Chan wrote:
>
>> This may not be that useful in all circumstances - I always send dates as
>> milliseconds since the UNIX epoch as 64-bit signed integers. Those are *way*
>> faster to parse.
>
> Yes. It's ridi
On Sep 9, 2013, at 11:46 , Tom Davie wrote:
> On 9 Sep 2013, at 20:29, Rick Mann wrote:
>
>>
>> On Sep 9, 2013, at 09:25 , Maxthon Chan wrote:
>>
>>> This may not be that useful in all circumstances - I always send dates as
>>> milliseconds since the UNIX epoch as 64-bit signed integers. T
On Sep 9, 2013, at 3:45 PM, Patrick Cusack wrote:
> I appreciate everyone's replies. It was a question asked in complete
> humility. I agree that computers can do analysis much better than humans and
> that the less code you write, the less you have to debug, so ARC makes a lot
> of sense. My q
To me, this seems like the wrong direction to move. This is sort of like
saying you want to convert your OS X app to a Classic Mac OS app maintain
support for some Mac OS API.
I'd go 64-bit only for your main app. I'd leave the 32-bit helper separate.
Isolate your dependence on this component. If
I have a helper tool that needs to use both C-based QuickTime/QTKit as well
as AV Foundation to process things for the main app.
Currently I am actually using two helper tools - one 32bit app to work with
QuickTime (since some of the old API will not work in 64bit), and a second
32/64bit app to w
> I’m not sure if you meant that ironically, but it’s absolutely not premature.
> I’ve run into major NSDateFormatter bottlenecks — as in “hm, over half the
> time to open this file is spent inside NSDateFormatter” — at least twice, and
> the author of the blog post I linked to says that he also
On 2013 Sep 09, at 13:14, Marcel Weiher wrote:
On 2013 Sep 9, at 18:11 , Jens Alfke wrote:
[...]
[fg160,160,160;16:34:40.488| [fg0,128,0;[;NSDateFormatter took
26.97 µsec
[fg160,160,160;16:34:48.649| [fg0,128,0;[;CBLParseDatetook
0.47 µsec (58x)
Now, the tradeoff is that the o
45 matches
Mail list logo
