Hi
I'm generating a NSAttributedString which looks like the following:
function_name_1
disassembled code output
disassembled code output
disassembled code output
function_name_2
disassembled code output
disassembled code output
function_name_3
disassembled code output
disassembled code output
dis
On 24 Aug 2014, at 01:23, Jens Alfke wrote:
>
>> On Aug 23, 2014, at 12:46 AM, Gerriet M. Denkmann
>> wrote:
>
>> Works fine and is twice as fast.
>
> That approach is a bit naive, as it's going to spawn a huge number of
> [dispatched blocks] (something like O(n) of them, I think.) Also, o
On Aug 23, 2014, at 7:29 PM, Roland King wrote:
> CoreText
going there now to see what it yields
-rags
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments to the list.
Contact the moderato
> On 24 Aug 2014, at 8:49 am, Raglan T. Tiger wrote:
>
>
> On Aug 23, 2014, at 5:43 PM, Kyle Sluder wrote:
>
>> So what if Zöe’s name has an umlaut? As the documentation describes, that
>> can result in two separate glyphs.
>>
>
> apparently -glyphWithName: returns all the paths required t
On Aug 23, 2014, at 5:49 PM, Raglan T. Tiger wrote:
>
>
>> On Aug 23, 2014, at 5:43 PM, Kyle Sluder wrote:
>>
>> So what if Zöe’s name has an umlaut? As the documentation describes, that
>> can result in two separate glyphs.
>
> apparently -glyphWithName: returns all the paths required to ma
On Aug 23, 2014, at 6:49 PM, Raglan T. Tiger wrote:
> this is what we want but again to the original question how to get glyphs
> unicode so we don’t have to know the names
I will look into the NSLayoutManager suggestions as they have appeared in otter
searches
___
On Aug 23, 2014, at 5:43 PM, Kyle Sluder wrote:
> So what if Zöe’s name has an umlaut? As the documentation describes, that can
> result in two separate glyphs.
>
apparently -glyphWithName: returns all the paths required to make the unicode
character
at this link you will see Zöe interpret
If you are going to go the core data route, you should look into using it with
this most excellent tool:
https://github.com/rentzsch/mogenerator
Shane
Sent from my iPhone
> On Aug 22, 2014, at 7:25 PM, Jim Geist wrote:
>
> I don’t know of any storage quotas, I’ve seen debug logging fill up
On Aug 23, 2014, at 6:27 PM, Cosmin Apreutesei
wrote:
> I was wondering if anyone knows which of the various NSWindow methods
> have asynchronous operation and which are blocking, with their effects
> guaranteed after the call?
From what perspective? All of the corresponding object and delegat
On Aug 23, 2014, at 4:30 PM, "Raglan T. Tiger" wrote:
>
>
> -rags
>
>
>
>> On Aug 23, 2014, at 3:30 PM, Kyle Sluder wrote:
>>
>> So the user types "abcdef" into
>
> no, more like “Zoe’s First Birthday"
So what if Zöe’s name has an umlaut? As the documentation describes, that can
result
-rags
On Aug 23, 2014, at 3:30 PM, Kyle Sluder wrote:
> So the user types "abcdef" into
no, more like “Zoe’s First Birthday"
- rags
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do not post admin requests or moderator comments t
I was wondering if anyone knows which of the various NSWindow methods
have asynchronous operation and which are blocking, with their effects
guaranteed after the call?
I'm interested in these in particular:
orderFront -- ?
orderOut-- ?
makeKeyWindow -- a
On Aug 23, 2014, at 3:30 PM, Kyle Sluder wrote:
> So the user types "abcdef" into your field and hits OK; you dismiss the
> font panel and try to get the glyphs for "a", "b", "c", "d", "e", and
> "f"?
short of dismissing the font panel, yeah
already have code that processes all the paths in a
On Sat, Aug 23, 2014, at 11:26 AM, Raglan T. Tiger wrote:
>
> > So the question I have is: what are you actually trying to do?
>
> Generally speaking, display the NSFontPanel with an accessory view
> containing a NSTextField, OK and Cancel buttons.
>
> The user picks a font, types a phrase and c
> On Aug 23, 2014, at 11:23 AM, Jens Alfke wrote:
>
> it's going to spawn a huge number of dispatch queues (something like O(n) of
> them, I think.)
Oops, I meant 'dispatched blocks'. Which still have overhead because the block
contexts are heap-allocated.
—Jens
> On Aug 23, 2014, at 9:57 AM, Carl Hoefs
> wrote:
>
> However, specifically on iOS, I take it that SQLite is the *only* database
> available
It's the only one built into the OS with a public API. But there are a lot of
options if you're willing to build and link in your own database — Tokyo
> On Aug 23, 2014, at 12:46 AM, Gerriet M. Denkmann
> wrote:
> Works fine and is twice as fast.
That approach is a bit naive, as it's going to spawn a huge number of dispatch
queues (something like O(n) of them, I think.) Also, once the array sizes start
getting smaller than a cache line the
The first part of this method shows how to get the glyph from any character
Works fine with non-Latin characters such as Japanese too
- (UIBezierPath *)bezierPathFromChar:(NSString *)aChar inFont:(CTFontRef)aFont {
// Buffers
unichar chars[1];
CGGlyph glyphs[1];
// Copy the ch
From Realm home page: "Realm is not built on SQLite."
On 23 Aug 2014, at 17:57, Carl Hoefs wrote:
>
> On Aug 23, 2014, at 9:23 AM, Glenn L. Austin wrote:
>
>> CoreData is not a database (according to Marcus Zarra -- and he should
>> know). Even though it *can* use an SQLite data store (and
On Aug 23, 2014, at 9:23 AM, Glenn L. Austin wrote:
> CoreData is not a database (according to Marcus Zarra -- and he should know).
> Even though it *can* use an SQLite data store (and most people do that), it
> doesn't depend upon SQLite functionality.
However, specifically on iOS, I take i
On Aug 23, 2014, at 10:26 AM, Raglan T. Tiger wrote:
> So I need some mechanism to take the entered character, get its name and
> retrieve the glyph.
If NSFont had a get by unicode … problem solved.
-rags
___
Cocoa-dev mailing list (Cocoa-dev@lists
> So the question I have is: what are you actually trying to do?
Generally speaking, display the NSFontPanel with an accessory view containing a
NSTextField, OK and Cancel buttons.
The user picks a font, types a phrase and clicks OK.
I now take the phrase and get the glyphs for each character
CoreData is not a database (according to Marcus Zarra -- and he should know).
Even though it *can* use an SQLite data store (and most people do that), it
doesn't depend upon SQLite functionality.
SQLite is built-in and available pretty much everywhere, but you need to learn
a bit of SQL.
On A
There is also YapDatabase https://github.com/yaptv/YapDatabase -- a KV-store
built atop SQLite.
On 23 Aug 2014, at 16:17, Carl Hoefs wrote:
> Wow, I didn’t realize there were so many options. I’ll be looking into all of
> these (SQLite, CoreData, FMDB, Realm) to see which fits into my project'
Wow, I didn’t realize there were so many options. I’ll be looking into all of
these (SQLite, CoreData, FMDB, Realm) to see which fits into my project's
design best (and which appeals to me).
Thanks for all the great suggestions!
-Carl
___
Cocoa-dev
FMDB is also a very popular and simple Objective-C wrapper to SQLite
You can be up and running with it in minutes.
And it works on OS X the same so it's portable.
Sent from my iPhone
___
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
Please do n
> I encountered this same issue. Making the window a one-shot window
> (window.oneShot = YES) works around it.
Hi Ken,
Thank you very much, that worked!
I also posted this question on so[1] if you want to answer it there too.
Thanks again,
Cosmin.
[1] http://stackoverflow.com/questions/2545
I searched the Swift book for "thread" and found nothing.
A quicksort algorithm works like:
quicksort(array)
{
partition(array)
quicksort( left side)
quicksort( right side)
}
On Obj-C I just did:
quicksort(array)
{
partition(array)
dispatch_apply( 2, queu
I would recommend taking a look into the newly released Realm
(http://realm.io). I’ve been using it for the last couple of weeks and I’d bet
it’s a solid alternative to SQL base databases / ORMs (SQLite). APIs are really
easy to grasp and queries to the database are human-friendly and powerful.
29 matches
Mail list logo
