Re: SecStaticCodeCheckValidity fails when app is lauched from Terminal

2016-09-27 Thread じょいすじょん 
Have you also tried NSWorkspace for this?

> On 2016 Sep 27, at 2:38, Markus Spoettl  wrote:
> 
> It is an OSX Cocoa GUI application. I have always started it from the command 
> line by executing the executable inside the bundle. While this always worked, 
> it no longer seems to.
> 
> That said, it didn't occur to me that there's a proper way, by using the 
> "open" command. Thanks for the tip, this works nicely for my purposes!
> 
> Regards
> Markus
> 
> On 26/09/16 19:18, Gary L. Wade wrote:
>> In what way did you start your app from the Terminal?  Is this
>> WindowServer-based or a command line app?  Not sure your purpose in starting
>> from the command line if WindowServer-based, but have you tried launching it
>> with the open command where the argument is the .app bundle vs possibly 
>> another
>> way like the actual executable?
>> --
>> Gary L. Wade
>> http://www.garywade.com/
>> 
>>> On Sep 26, 2016, at 2:44 AM, Markus Spoettl >> > wrote:
>>> 
>>> I'm using SecStaticCodeCheckValidity() to self check the signature of my own
>>> app when it is launched. This works fine and always has.
>>> 
>>> All of a sudden, the call to SecStaticCodeCheckValidity() fails if (and only
>>> if the application) is started from the Terminal. When I start the very same
>>> app from the Dock or from the Finder the check succeeds (iow. the call 
>>> returns
>>> noErr).
>>> 
>>> I don't know exactly when it started failing. I only know it definitely 
>>> worked
>>> before on previous versions of El Capitan but now it no longer does (v 
>>> 10.11.6).
>>> 
>>> Any ideas?
>>> 
>>> Regards
>>> Markus
>>> --
>>> __
>>> Markus Spoettl
>>> ___
>>> 
>>> 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:
>>> https://lists.apple.com/mailman/options/cocoa-dev/garywade%40desisoftsystems.com
>>> 
>>> This email sent to garyw...@desisoftsystems.com
>> 
> 
> 
> -- 
> __
> Markus Spoettl
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/dangerwillrobinsondanger%40gmail.com
> 
> This email sent to dangerwillrobinsondan...@gmail.com


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

NSTextView read real text content (without 0xA added by wordwrap)

2016-09-27 Thread Felipe Monteiro de Carvalho 
Hello,

I have a normal NSTextView and I would like to programatically read
the text inside it.

This is trivial, just call txt.string or txt.textContainer.string

But the resulting string contains line endings which are added in the
places where the word-wrap takes places, and I need the raw text,
without such added line endings.

Note that I don't want to disable word-wrap!

I assume that Cocoa must know the original text, because otherwise it
would not be able to change the wraping when the control is resized.
Any ideas how to obtain the original text? I tried google to no luck
:( Seams like noone had this problem before.

And no, manually removing all line endings is not what I want, because
some line endings are part of the real text, not added by word-wrap.

thanks in advance,
-- 
Felipe Monteiro de Carvalho
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-27 Thread Alastair Houghton 
On 27 Sep 2016, at 02:17, Slipp Douglas Thompson  
wrote:
> 
> I'm just going to throw this out there as a solution, not because I recommend 
> this approach (it's API misuse after all) but because it would work.
> 
> Instead of using an `NSString *` you could use a `SEL` (AKA `struct 
> objc_selector *`) since SELs are guaranteed to be unique for each given 
> string they represent (within a process; AFAIR).

Indeed, they’re interned by the Objective-C runtime.  However, this is a 
blessing and a curse; it’s a blessing in that comparing with a selector will be 
fast, you can use “==“ to do the comparison, and the resulting code will be 
easy to read.  It’s a curse in that it means you must choose a unique selector. 
 So @selector(mediaLibraryLoaded) is unlikely to be a good choice; something 
like @selector(com:mycompany:mediaLibraryLoaded) might be.

> My 2¢: I'm still in favor of making all usages of `context` in your app 
> `NSObject *`s or `nil` because sometimes you do want to store an 
> `NSDictionary *` or other data in `context` that's meant to be read later.

The context value is not retained (and there’s no obvious guarantee about when 
you can expect that it won’t be used again; assuming that you won’t be called 
with your context value immediately after deregistering for KVO notifications 
will probably result in the creation of a subtle race condition).  Also, other 
code might result in you receiving a non-nil pointer that doesn’t point to an 
object.  The safest way really is to take the address of a static variable in 
your code and use that; there are, as you rightly suggest, alternative 
addresses you could use (a selector, or a function address would both work, as 
would a dynamically allocated address, provided you stored it somewhere).

> But if you're stuck with using other libs that don't use `NSObject *`s or 
> `nil`, or if you really want to ensure your code won't crash because its 
> making assumptions about what's in the  `context` your code registered, then 
> I acknowledge your case.  Key point: I personally wouldn't use the `SEL` 
> approach, but still.

The SEL approach is better, modulo the requirement for the name to be unique.  
But the idiom used by most of us is to take the address of a static variable, 
and I’d recommend sticking to that.

The important point in all of this, though, is that you can’t safely 
dereference the context pointer, because you don’t know what it is.  You may 
*think* you do, because you’ve supplied *one* possible value for it, but other 
code that you don’t control can supply other non-nil values and they will point 
at whatever that code chose to point them at, which probably wasn’t the same as 
your choice.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Stupid objective-c question

2016-09-27 Thread Alastair Houghton 
On 27 Sep 2016, at 05:31, Britt Durbrow  
wrote:
> 
> FWIW, it’s currently an implementation detail that SELs do map into the 
> global address space in a way that doesn’t collide with anything else; but 
> technically, they are in their own address space and the system could map 
> them otherwise in a manner that does have collisions with other stuff.

That’s true.  IIRC GNUStep SEL values don’t work the same way as they do with 
the Apple/NeXT runtime, so this trick wouldn’t work there.

> In practice, I don’t think that will ever happen, because a) too much 
> existing code makes the assumption that a SEL is de-referenceable or 
> otherwise depends on this implementation detail; and b) we have 64-bit 
> addressing, so we’re not going to run out of address space such that making 
> that change would be advantageous.

Agreed, it seems unlikely that Apple would change it; not impossible, but quite 
unlikely.  As I say, relying on it means your code won’t straightforwardly port 
to GNUStep, but most of us don’t care too much about that.

Kind regards,

Alastair.

--
http://alastairs-place.net


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextView read real text content (without 0xA added by wordwrap)

2016-09-27 Thread Graham Cox 

> On 27 Sep 2016, at 5:31 PM, Felipe Monteiro de Carvalho 
>  wrote:
> 
> But the resulting string contains line endings which are added in the
> places where the word-wrap takes places, and I need the raw text,
> without such added line endings.


Are you sure about that? I’ve never seen the text view add line endings to the 
underlying raw text - that’s just not how text layout works.

(Indeed I just made a quick test case and I don’t see that happening).

—Graham



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextView read real text content (without 0xA added by wordwrap)

2016-09-27 Thread Felipe Monteiro de Carvalho 
On Tue, Sep 27, 2016 at 11:07 AM, Graham Cox  wrote:
> Are you sure about that? I’ve never seen the text view add line endings to 
> the underlying raw text - that’s just not how text layout works.
> (Indeed I just made a quick test case and I don’t see that happening).

What I am writing is a large cross-platform library, so indeed it
could be that the line endings were added by something else, I'll
recheck.

But to be sure I will test the same thing as you are testing, you are
reading the text via NSTextView.string ?

-- 
Felipe Monteiro de Carvalho

___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextView read real text content (without 0xA added by wordwrap)

2016-09-27 Thread Felipe Monteiro de Carvalho 
On Tue, Sep 27, 2016 at 11:26 AM, Felipe Monteiro de Carvalho
 wrote:
> But to be sure I will test the same thing as you are testing, you are
> reading the text via NSTextView.string ?

By the way, not sure if this makes a difference, but the original text
was added via NSTextView.string

It is not text inputted by the user.

-- 
Felipe Monteiro de Carvalho
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextView read real text content (without 0xA added by wordwrap)

2016-09-27 Thread Graham Cox 

> On 27 Sep 2016, at 7:26 PM, Felipe Monteiro de Carvalho 
>  wrote:
> 
> But to be sure I will test the same thing as you are testing, you are
> reading the text via NSTextView.string ?


Yes. I set up a very simple situation where the NSTextView’s delegate simply 
logs the textView.string as I type. No line breaks unless I actually type one 
(option-return).

Also, in your OP, you mention textContainer.string. There’s no such property. 
You probably meant textStorage.string, but let’s make sure. I tried that also, 
and it works exactly the same.

It would be pretty hard for the word-wrap done by the view to affect the raw 
string, because it’s a major violation of model-controller-view principles. If 
something else is adding those, it must be going well out of its way to do it.

—Graham



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextView read real text content (without 0xA added by wordwrap)

2016-09-27 Thread Graham Cox 

> On 27 Sep 2016, at 7:28 PM, Felipe Monteiro de Carvalho 
>  wrote:
> 
> By the way, not sure if this makes a difference, but the original text
> was added via NSTextView.string
> 
> It is not text inputted by the user.
> 

Well, a NSTextView can’t have a string unless it came from somewhere, therefore 
that isn’t the ‘original’ string. Perhaps the original string has those line 
breaks? If it was cut+pasted from a block of text that had forced line endings, 
NSTextView will preserve those, but it definitely never adds them as part of 
its layout process.

—Graham



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextView read real text content (without 0xA added by wordwrap)

2016-09-27 Thread Jens Alfke 

> On Sep 27, 2016, at 2:07 AM, Graham Cox  wrote:
> 
> Are you sure about that? I’ve never seen the text view add line endings to 
> the underlying raw text - that’s just not how text layout works.

+1. I’ve been using NSTextView since 2001 and I know for a fact that it doesn’t 
insert meta-characters like that on its own. Its contents are the string that 
you gave it (plus user edits, of course.)

—Jens
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: NSTextView read real text content (without 0xA added by wordwrap)

2016-09-27 Thread Felipe Monteiro de Carvalho 
Hello,

Sorry for the noise, it turns out that the bug was in my software after all!

thanks,
-- 
Felipe Monteiro de Carvalho
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: SecStaticCodeCheckValidity fails when app is lauched from Terminal

2016-09-27 Thread Chris Hanson 
How are you getting the URL that you pass to represent your application?

Could it be that you’re constructing the URL from a relative path when run from 
the command line, rather than the full path? (You can’t depend on being run 
from any particular working directory.)

  -- Chris

> On Sep 26, 2016, at 2:44 AM, Markus Spoettl  wrote:
> 
> I'm using SecStaticCodeCheckValidity() to self check the signature of my own 
> app when it is launched. This works fine and always has.
> 
> All of a sudden, the call to SecStaticCodeCheckValidity() fails if (and only 
> if the application) is started from the Terminal. When I start the very same 
> app from the Dock or from the Finder the check succeeds (iow. the call 
> returns noErr).
> 
> I don't know exactly when it started failing. I only know it definitely 
> worked before on previous versions of El Capitan but now it no longer does (v 
> 10.11.6).
> 
> Any ideas?
> 
> Regards
> Markus
> -- 
> __
> Markus Spoettl
> ___
> 
> 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:
> https://lists.apple.com/mailman/options/cocoa-dev/cmh%40me.com
> 
> This email sent to c...@me.com


___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: SecStaticCodeCheckValidity fails when app is lauched from Terminal

2016-09-27 Thread Markus Spoettl 

On 27/09/16 22:39, Chris Hanson wrote:

How are you getting the URL that you pass to represent your application?

Could it be that you’re constructing the URL from a relative path when run
from the command line, rather than the full path? (You can’t depend on being
run from any particular working directory.)


Not sure what you mean by URL, I'm merely executing the app's executable from 
the command line. Assuming the My.app bundle is located in 
"~/Projects/My/Debug", I cd into "~/Projects/My" and execute 
"./Debug/My.App/Contents/MacOS/My".


I'm starting the app from the command line in cases when I want to test a 
certain localization using the -AppleLanguages '(xx)' command line option, which 
is quite handy.


As I said this used to work fine, but now the code signing signature is being 
rejected. However, using the "open" command works fine for me.


Regards
Markus
--
__
Markus Spoettl
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: SecStaticCodeCheckValidity fails when app is lauched from Terminal

2016-09-27 Thread Chris Hanson 
On Sep 27, 2016, at 1:54 PM, Markus Spoettl  wrote:
> 
> On 27/09/16 22:39, Chris Hanson wrote:
>> How are you getting the URL that you pass to represent your application?
>> 
>> Could it be that you’re constructing the URL from a relative path when run
>> from the command line, rather than the full path? (You can’t depend on being
>> run from any particular working directory.)
> 
> Not sure what you mean by URL, I'm merely executing the app's executable from 
> the command line. Assuming the My.app bundle is located in 
> "~/Projects/My/Debug", I cd into "~/Projects/My" and execute 
> "./Debug/My.App/Contents/MacOS/My”.

I mean, how are you constructing the SecStaticCodeRef that you pass to 
SecStaticCodeCheckValidity()?

  -- Chris



___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: Lifecycle for custom NSURLProtocol properties

2016-09-27 Thread Jens Alfke 

> On Sep 26, 2016, at 10:42 PM, Allan Odgaard  
> wrote:
> 
> I am making use of NSURLProtocol’s `setProperty:forKey:inRequest:` but it 
> seems that my custom properties outlive the URL request, and even if I 
> explicitly call `removePropertyForKey:inRequest:` after my request is done, 
> it would appear that my properties are still being retained by something.

Are they actually getting leaked? Does the memory usage of these values keep 
increasing over time?

> I guess this is a bit of a black box, but does anyone have any 
> info/experience with this?

I’d recommend asking on the macnetworkprog list; there are more folks there 
(including Quinn) who might now for sure.

—Jens
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Re: SecStaticCodeCheckValidity fails when app is lauched from Terminal

2016-09-27 Thread Markus Spoettl 

On 27/09/16 22:57, Chris Hanson wrote:

On Sep 27, 2016, at 1:54 PM, Markus Spoettl  wrote:


On 27/09/16 22:39, Chris Hanson wrote:

How are you getting the URL that you pass to represent your application?

Could it be that you’re constructing the URL from a relative path when run
from the command line, rather than the full path? (You can’t depend on being
run from any particular working directory.)


Not sure what you mean by URL, I'm merely executing the app's executable from the command line. Assuming 
the My.app bundle is located in "~/Projects/My/Debug", I cd into "~/Projects/My" and 
execute "./Debug/My.App/Contents/MacOS/My”.


I mean, how are you constructing the SecStaticCodeRef that you pass to 
SecStaticCodeCheckValidity()?


OK, here the full code:

CFStringRef reqStr = 

SecStaticCodeRef ref = NULL;
SecRequirementRef req = NULL;

CFURLRef bURL = CFBundleCopyBundleURL(CFBundleGetMainBundle());
OSStatus status = SecStaticCodeCreateWithPath(bURL, kSecCSDefaultFlags, &ref);

if ((ref != NULL) && (status == noErr)) {
  status = SecRequirementCreateWithString(reqStr, kSecCSDefaultFlags, &req);

  if ((req != NULL) && (status == noErr)) {
// this fails
status = SecStaticCodeCheckValidity(ref, kSecCSCheckAllArchitectures, req);


Regards
Markus
--
__
Markus Spoettl
___

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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com