Re: help with debugging

2014-11-18 Thread KappA
Just a thought off the top (please excuse me if I'm far off)... but what
about wrapping in a @try/@catch to handle the exception and get more
details? Again, sorry if I'm far off, still having my first cup of coffee.

https://developer.apple.com/library/ios/documentation/Cocoa/Conceptual/Exceptions/Tasks/HandlingExceptions.html

On Tue, Nov 18, 2014 at 1:30 PM, Sean McBride 
wrote:

> On Tue, 18 Nov 2014 10:25:07 -0800, Jens Alfke said:
>
> >> Those offsets tell you how far into the function (in bytes I think) it
> >was.  You can indeed bring that back to a line number.  See here:
> >>
> >>  >symbolication.html>>
> >
> >That info is for live debugging in lldb
>
> Not exclusively it isn't.
>
> >but Phil said these are crash
> >logs coming from users
>
> No he didn't.  He said in fact that it doesn't crash, but there's a
> backtrace from an uncaught exception in Console logs.
>
> >so he's going to need a tool that symbolicates a
> >log file. I know there are tools for that but I don't know offhand what
> >they are, since I've never had to do this myself; can anyone fill in the
> gaps?
>
> It's in the doc I linked to.  Scroll to the "lldb.macosx.crashlog" part.
>
> I've never tried with an exception backtrace, but there's likely enough
> info it that doc to do it all.
>
> Cheers,
>
> --
> 
> Sean McBride, B. Eng s...@rogue-research.com
> Rogue Researchwww.rogue-research.com
> Mac Software Developer  Montréal, Québec, Canada
>
>
>
> ___
>
> 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/rejekted%40gmail.com
>
> This email sent to rejek...@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

Re: Text System Locks Up - Can't Find Reason

2014-06-12 Thread KappA
That's exactly what I said.

>> Not sure why it doesn't like that property when using IB.

To me, that setting took your broken and hung app and made it work just as
your fast one. I'll leave the rest up to you to figure out why. And if you
read the docs about that setting, it seems to be giving you the "opposite"
effect of it's documented "benefit".

Good luck!


On Thu, Jun 12, 2014 at 1:21 PM, Seth Willits  wrote:

> On Jun 11, 2014, at 6:46 PM, KappA  wrote:
>
> > For some reason it doesn't like the below - you need to comment that
> out, and uncheck that option in IB:
> >
> > self.textView.layoutManager.allowsNonContiguousLayout = YES;
> >
> > At least that's how I fixed it :) Not sure why it doesn't like that
> property when using IB.
>
> That's not fixing it, it's just avoiding the problem. "Fast" has it
> enabled. It's on by default in every text view.
>
>
> --
> Seth Willits
>
> ___
>
> 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/rejekted%40gmail.com
>
> This email sent to rejek...@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

Re: What iOS device?

2014-01-30 Thread KappA
I came across this the other day. Have you already looked at this?

http://stackoverflow.com/questions/448162/determine-device-iphone-ipod-touch-with-iphone-sdk


On Fri, Jan 31, 2014 at 1:19 AM, Gerriet M. Denkmann
wrote:

> I want (for logging purposes only) to know the kind of iOS device being
> used.
>
> UIDevice model or localizedModel returns just "iPhone", but I want
> something like "iPhone 4s" or "iPad Air" etc.
> NSProcessInfo physicalMemory can be used to distinguish between some
> models, but not all.
>
> Then there is sysctlbyname("hw.model",...) but this returns cryptic stuff
> like: "J71AP"  or "N94AP".
> Is there some official table to convert this to something more readable?
> (There is  but I
> would like something coming from Apple).
>
> What else can be done?
>
> Gerriet.
>
>
>
> ___
>
> 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/rejekted%40gmail.com
>
> This email sent to rejek...@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

Re: Mixing Obj-C and C "methods"

2013-07-30 Thread KappA
I sometimes just access my objc-objects from a C thread-proc via the
AppDelegate (providing there's a trail to the object I need, which there
usually is)... If the callback void pointer parameter isn't being used for
something else, you can simply cast the object in there... or if you need
multiple parameters you can create a struct that stores what you need and
pass that. Not sure if this helps but figured I'd mention it.

AppDelegate *d = [[UIApplication sharedApplication] delegate];



On Tue, Jul 30, 2013 at 8:53 AM, lowell  wrote:

> The first two parameters to the function have to be an id and a SEL ...
>
> typedef id (*IMP)(id, SEL, ...);
>
> ... (this is where we get self and _cmd, by the way) followed by the rest
> of the method params, if any.
>
>
> lowell
>
>
> On Jul 30, 2013, at 12:59 AM, Vincent Habchi  wrote:
>
> > Hi everybody,
> >
> > I have a very simple question: if I embed a C-function (more precisely,
> a callback from an external C-library) in an Obj-C object, can I expect
> this function to behave like a regular method? I.e. can it freely access
> ‘self’ and other attributes?
> >
> > Thanks a lot!
> > Vincent
> >
> >
> >
> >
> > ___
> >
> > 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/lowellv%40me.com
> >
> > This email sent to lowe...@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/rejekted%40gmail.com
>
> This email sent to rejek...@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

Re: Icon Overlay on Mac OSX

2012-08-02 Thread KappA
Thanks. Yeah this too seems a bit messy, as you also have to take the quick
look preview into consideration. (when switching the various Finder views).

On Thu, Aug 2, 2012 at 10:37 PM, Charles Srstka wrote:

> On Aug 2, 2012, at 9:26 PM, Jens Alfke  wrote:
>
> On Aug 2, 2012, at 6:54 PM, KappA  wrote:
>
> get the attributes
> get the icon
> composite the overlay
> set the icon
> set the attributes
>
>
> This has an obvious race condition, but it should work most of the time.
> If you don't change the icon often, you should be OK.
>
>
> Again, except for the fact that you will overwrite any custom icons that
> the user has decided to put on the files.
>
> Charles
>
>
___

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: Icon Overlay on Mac OSX

2012-08-02 Thread KappA
I have been playing around with that -

get the attributes
get the icon
composite the overlay
set the icon
set the attributes

When I print out the attributes before/after they match - now this only
works for files that you have access to (it failed for a few files owned by
root).

I am not sure how this affects MD5 checksum, I am going to look into that
next...

On Thu, Aug 2, 2012 at 9:21 PM, Alfian Busyro wrote:

> Which you guys mean I have to create the overlay to an Image it self then
> stick it to a file icon ?
> I'd try this before but nothing was changed. maybe I'll have try this once
> again.
>
> And for file attributes, can we use setAttributes:ofItemAtPath:**error:
> from NSFileManager ?
> because there is NSFileModificationDate attributes for in this function.
>
> Regards,
> Alfian
>
> On 12/08/03 5:47, Charles Srstka wrote:
>
>> On Aug 2, 2012, at 3:41 PM, KappA  wrote:
>>
>>  I believe setIcon updates the file modification date... (please check as
>>> I
>>> can't remember for sure)... which might go against what a file tracking
>>> system might be trying to do.
>>>
>>> i.e. will give false file modification updates because of setting the
>>> updated icons.
>>>
>>> If there is a way to do that without updating the file attributes, it
>>> would
>>> work perfectly...
>>>
>> In addition to this, it will hose any custom icons that the user might
>> have set on the files.
>>
>> Charles
>>
>> __**_
>>
>> 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<http://lists.apple.com>
>>
>> Help/Unsubscribe/Update your Subscription:
>> https://lists.apple.com/**mailman/options/cocoa-dev/**
>> alfian.busyro%40kddi-web.com<https://lists.apple.com/mailman/options/cocoa-dev/alfian.busyro%40kddi-web.com>
>>
>> This email sent to alfian.bus...@kddi-web.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<http://lists.apple.com>
>
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/**mailman/options/cocoa-dev/**rejekted%40gmail.com<https://lists.apple.com/mailman/options/cocoa-dev/rejekted%40gmail.com>
>
> This email sent to rejek...@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


Re: Icon Overlay on Mac OSX

2012-08-02 Thread KappA
I believe setIcon updates the file modification date... (please check as I
can't remember for sure)... which might go against what a file tracking
system might be trying to do.

i.e. will give false file modification updates because of setting the
updated icons.

If there is a way to do that without updating the file attributes, it would
work perfectly...

Kappa.

On Thu, Aug 2, 2012 at 4:22 PM, Uli Kusterer
wrote:

> On 02.08.2012, at 07:47, Jens Alfke  wrote:
> > Set custom icons for the files? (I have no idea how custom file icons
> are done nowadays, though. They used to be stored in the resource fork, but
> that's been deprecated for a decade now. Maybe they're in extended file
> attributes?)
>
>  NSWorkspace has a setIcon: forPath: method (or something like that) for
> this purpose. I think it was added around 10.6, might even be older. Or
> maybe it was NSFileManager. I mentioned it previously in this thread, not
> gonna look it up a second time.
>
> Cheers,
> -- Uli Kusterer
> "The Witnesses of TeachText are everywhere..."
>
>
>
>
> ___
>
> 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/rejekted%40gmail.com
>
> This email sent to rejek...@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


Re: App Crashing in ARC !!

2012-02-24 Thread KappA
Based on this line:

 -[NSPanel release]: message sent to deallocated instance 0x111c74a60*

And this from the stack trace:

*#2  0x7fff8ff49ca0 in CFRelease ()*

Looks like you're over releasing. Perhaps ensure that the object is
declared as "strong" so that you keep a reference of it around?

This is just my guess based on the above. You should enable NSZombie and
malloc stack and see if you get any more info. If not, at least you have an
idea that it's the NSPanel, and you can take a closer look at that in your
code.

I happened to see this on the documentation for NSAlert which looks
interesting...

**
Link<https://developer.apple.com/library/mac/#documentation/Cocoa/Reference/ApplicationKit/Classes/NSAlert_Class/Reference/Reference.html>Special
Considerations

This is a compatibility method. It is designed for easy adoption by
applications migrating from the corresponding function-based API. This
method uses earlier return
values—NSAlertDefaultReturn<https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSPanel_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSAlertDefaultReturn>
,NSAlertAlternateReturn<https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSPanel_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSAlertAlternateReturn>,
and 
NSAlertOtherReturn<https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSPanel_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSAlertOtherReturn>—compatible
with the earlier API, rather than the return values defined by the
NSAlert class,
described in “Button Return
Values.”<https://developer.apple.com/library/mac/documentation/Cocoa/Reference/ApplicationKit/Classes/NSAlert_Class/Reference/Reference.html#//apple_ref/doc/constant_group/Button_Return_Values>

Unless you must maintain compatibility with existing alert-processing code
that uses the function-based API, you should allocate (alloc) and
initialize (init) the object, and then set its attributes using the
appropriate methods of the NSAlert class.
**

Anyways, good luck and maybe someone else might chime in with a more
conclusive answer.

Thanks,
Kappa


On Thu, Feb 23, 2012 at 3:01 PM, Fritz Anderson wrote:

> On 22 Feb 2012, at 9:31 PM, Naresh Kongara wrote:
>
> > I'm creating the alert with class method in NSAlert and running it with
> runModal.
> >
> > NSAlert *alert =[NSAlert
> alertWithMessageText:defaultButton:alternateButton:otherButton:informativeTextWithFormat:];
> > if ([alert runModal] == NSAlertDefaultReturn) {
> > //Code
> > }
> > This crash is happening only after we migrated to ARC. I tried with
> analyzer and Zombies, but no success in finding the cause for the crash.
>
> You've provided a skeleton of how you intend to do something, but nothing
> that shows what you are actually doing. You've provided nothing more than
> "make an alert and run it." If there is a bug in this section of your code,
> it's probably in the construction of the parameters to alertWith…, or in
> "Code."
>
> If your actual code is terribly complex, or proprietary, reduce it to a
> minimal case that reproduces it, and post it. Creating a minimal case will
> often show you your problem with no need to consult anyone else.
>
> Also: By any chance, are you running this alert on any thread other than
> the main one? You can't do that. You'll crash.
>
>— F
>
>
> ___
>
> 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/rejekted%40gmail.com
>
> This email sent to rejek...@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

Re: What are the best macros to use to know when compiling is for Mac OS X v.s. iOS?

2011-12-30 Thread KappA
Hello,

In short, it's probably best to use the TARGET_OS_IPHONE macro.

I used to use TARGET_OS_MAC when writing mac-specific code, but found that
even on iOS this was turned on making it a bit unreliable (or making you
redefine things in your own code)...

So it's probably a better idea to just stick to using the
TARGET_OS_IPHONE macro
as you can check it against both environments.

See this post:
http://stackoverflow.com/questions/3181321/which-conditional-compile-to-use-to-switch-between-mac-and-iphone-specific-code

Of course, if anyone on the list has a better solution, I'm all ears as
well.

Thanks,
Kappa

On Fri, Dec 30, 2011 at 11:44 AM, lbland  wrote:

> hi-
>
> What are the best macros to use to know when compiling is for Mac OS X
> v.s. iOS?
>
> thanks!-
>
> -lance
>
> ___
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/rejekted%40gmail.com
>
> This email sent to rejek...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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


Re: Passing NSPrintOperation* to CPP Function

2011-09-22 Thread KappA
Did you try to cast the parameter being passed so that it enforces the
definition - when calling the function?

m_bprinter->Setup((NSPrintOperation*)po);

Also, did you rename your .cpp file to .mm? (although that shouldn't really
matter much)...

And in the CPP header file, did you include the appropriate cocoa headers
for the "NSPrintOperation*" type?

As a workaround, you can always declare the CPP function in your class to
take a "void*" instead of "NSPrintOperation*" and then cast it back to a
"NSPrintOperation*" in the body of the function... and cast the "po" to a
"void*" when calling the CPP function...

Hope this helps.

Kappa

On Wed, Sep 21, 2011 at 11:10 PM, Jens Alfke  wrote:

> I think we’d need to see the actual code (or sections directly copied from
> it) to tell what’s going wrong.
> For example, the class declaration you provided wouldn’t work because
> Setup() isn’t declared as public, but I assume that’s just because you just
> typed in a couple of lines from it.
>
> —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:
> http://lists.apple.com/mailman/options/cocoa-dev/rejekted%40gmail.com
>
> This email sent to rejek...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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


Re: setTitleWithMnemonic

2011-08-31 Thread KappA
I never said I was using the "mnemonic" feature... just using it for setting
plain text. Is that what you are curious to see?

Kappa

On Thu, Sep 1, 2011 at 12:07 AM, Jerry Krinock  wrote:

>
> On 2011 Aug 31, at 16:42, Fritz Anderson wrote:
>
> > I don't think it's because there's a strong '90s-revival faction in the
> AppKit team
>
> Oh?  How about the '90s-revival faction who recently decided it was cool to
> be able to resize a window by dragging any edge? :))
>
> On 2011 Aug 31, at 18:51, KappA wrote:
>
> > I actually use that API to set the text successfully in my applications,
> so far without any problems.
>
> KappA, I'd like to see one of your applications, or a screenshot with those
> mnemonics.  Probably other readers would, too.  Please post a link.
>
> ___
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/rejekted%40gmail.com
>
> This email sent to rejek...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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


Re: setTitleWithMnemonic

2011-08-31 Thread KappA
Interesting.

I actually use that API to set the text successfully in my applications, so
far without any problems.

Thanks,
Kappa

On Wed, Aug 31, 2011 at 7:42 PM, Fritz Anderson wrote:

> On 31 Aug 2011, at 2:00 PM, Rajendran P wrote:
>
> > is it advisable to use the API setTitleWithMnemonic ? the document
> discussion
> > says
> >
> > "Discussion
> > Mnemonics are not supported in Mac OS X. "
> >
> > strangely , the API is not deprecated
>
> Given that the method has never had any effect in the ten years Mac OS X
> has existed, I'm not sure why you wonder if it is advisable to use it
> anyway? Mnemonics are not displayed, and there is no way to trigger them.
>
> The API probably carried over from NeXTStep or possibly the Yellow Box (the
> long-abandoned Cocoa for Windows). It is deprecated for NSMenuItem. You'd
> have to ask Apple why it hasn't been dropped. I don't think it's because
> there's a strong '90s-revival faction in the AppKit team, so I'm guessing
> it's just inertia.
>
>— F
>
> ___
>
> 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:
> http://lists.apple.com/mailman/options/cocoa-dev/rejekted%40gmail.com
>
> This email sent to rejek...@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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

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