Re: Problem with distributed objects in GUI cocoa apps
Hi Costas, I'd be interested in hearing the results of you following up NSXPCConnection. When I read through the documentation about a year ago, it is focussed around providing a xpcservice which is a bundled executable within an application, and the application communicates with it using NSXPCConnection. The NSXPCConnection can also be used for communicating with a LaunchAgent or a LaunchDaemon but I found the process of getting a LaunchAgent working as I found it difficult to separate what documentation was specific to an xpcservice and what was needed to be done differently for a LaunchAgent. I got there in the end, and I have the LaunchAgent side of things working and have a minimal project which demonstrates a working LaunchAgent. https://github.com/SheffieldKevin/LaunchAgent The big BUT though is. I could never see how you could use NSXPCConnection to communicate between two applications. I would be interested to know how this can be done which is why I'd be interested in hearing the results of your examination of NSXPCConnection. Kevin On 30 Apr 2014, at 07:49, Costas Chatzinikolas wrote: > Thank you very much. > > I had already solved the problem before yor response. > It had to do with disabling sandboxing at all. > > However i will follow your advice and start reading about NSXPCConnection. > > One quick question: DO API is not available on iOS. Do you know if > NSXPCConnection is? > > > 2014-04-24 8:32 GMT+03:00 Charles Srstka : > >> On Mar 30, 2014, at 3:28 AM, Costas Chatzinikolas < >> costas.chatziniko...@gmail.com> wrote: >> >>> Hi everyone, >>> >>> i recently made a set of 2 command lines apps in Cocoa, that use >>> Distributed objects to communicate. In fact, the first app is the client >>> that sends a message, the second app is the server the vends the object. >>> Everything works ok!!! >>> >>> Then i tried to make these 2 apps GUI based. I used the same code. The >>> server vends the object, but the client is unable to get the connection. >> It >>> always gets a nil connection. In fact when i check the number of >> available >>> connections from the client using: >>> >>> [NSConnection allConnections] >>> >>> it always return zero connections. The only difference in my code is that >>> in the GUI server app, i don't use: >>> >>> [[NSRunLoop currentRunLoop] run] >>> >>> since the GUI app has its own runLoop. >>> >>> I also have enabled the sandbox networking capabilities for both GUI >> apps. >>> >>> Has anyone experience this behavior before me? >>> >>> Thanks in advance... >> >> Distributed Objects is pretty old and crusty at this point. You might want >> to look into NSXPCConnection instead, which fixes a lot of problems that DO >> had, and is likely to be better supported. >> >> 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/ktam%40yvs.eu.com > > This email sent to k...@yvs.eu.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: Help with Help
On 30 Apr 2014, at 00:52, Gordon Apple wrote: > We would like to get a recommendation on the best way to generate a help > system for a fairly complex application. You might also try techwrl-list, they're the experts on help systems: http://www.techwr-l.com/frequently-asked-questions.html#subscribe signature.asc Description: Message signed with OpenPGP using GPGMail ___ 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: Problem with distributed objects in GUI cocoa apps
On Apr 29, 2014, at 11:49 PM, Costas Chatzinikolas wrote: > One quick question: DO API is not available on iOS. Do you know if > NSXPCConnection is? No, because iOS apps aren’t allowed to create new processes, so there would be no agents for you to communicate with. —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
JSONSerialization 'Garbage at end' error
Hi all,
I have Googled this issue for hours and tried various solutions suggested at
Stackoverflow, but can't seem to solve the following problem.
I am pulling JSON from here:
http://www.tenhorses.com/apps/meijburg/dotTAXDataHandler/dotTAXtaxNotesAPI.php
Both JSONLint, http://jsonformatter.curiousconcept.com and freeformatter.com
say this is valid JSON.
I am using the NSURLConnection delegate methods (appending data as it comes in
to a NSMutableData object) and are serialising the downloaded data in the
didFinishLoading like so:
NSError *error;
id jsonObject = [NSJSONSerialization JSONObjectWithData:self.container
options:NSJSONReadingAllowFragments error:&error];
if (error) {
NSLog(@"ERROR: %@", error);
}
else {
if ([self.type isEqual:@"people"] || [self.type isEqual:@"projects"] ||
[self.type isEqual:@"taxNotes"]) jsonObject = [jsonObject
objectForKey:@"items"];
NSString *notificationName = [NSString
stringWithFormat:@"%@DataDownloaded", self.type];
[[NSNotificationCenter defaultCenter]
postNotificationName:notificationName object:nil userInfo:[NSDictionary
dictionaryWithObject:jsonObject forKey:@"jsonArray"]];
[sharedConnectionList removeObject:self];
}
In short this sends off a notification with a pointer to an NSArray in case the
downloader object's type is 'people', projects' or 'taxNotes' and to a
NSDictionary in other cases.
Now here is the problem: although the JSON parses fine and populates a
UITableView without any issues, I am still getting the following error:
Error Domain=NSCocoaErrorDomain Code=3840 "The operation couldn’t be completed.
(Cocoa error 3840.)" (Garbage at end.) UserInfo=0xa2329a0
{NSDebugDescription=Garbage at end.}
I tested by creating an NSString from the data object and adding a few
characters at the end. Never does that reveal anything that should be there at
the end of the JSON string.
This, in itself, is slightly unsettling, but not critically wrong..
Has anybody here experienced a similar issue?
If so, can you tell me how to fix this?
Many thanks,
Diederik
___
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: Problem with distributed objects in GUI cocoa apps
So if i want to create two apps (one for Mac OS X - one for iOS) that speak to each other, i have to use sockets. Am i correct? 2014-04-30 17:16 GMT+03:00 Jens Alfke : > > On Apr 29, 2014, at 11:49 PM, Costas Chatzinikolas < > costas.chatziniko...@gmail.com> wrote: > > One quick question: DO API is not available on iOS. Do you know if > NSXPCConnection > is? > > > No, because iOS apps aren’t allowed to create new processes, so there > would be no agents for you to communicate with. > > —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: JSONSerialization 'Garbage at end' error
On Apr 30, 2014, at 8:20 AM, Diederik Meijer | Ten Horses wrote: > Now here is the problem: although the JSON parses fine and populates a > UITableView without any issues, I am still getting the following error: If the JSON parsed fine, then the error must be coming from somewhere else. A call to JSONObjectWithData: either returns a parsed object, or returns nil and sets the error. It doesn’t do both :) You’ll need to do some detective work to find out what function call that error is really coming from. At that point you can set a breakpoint and look at the input data. —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: JSONSerialization 'Garbage at end' error
I’m already doing downloads in my app using NSURLSession so I used my existing
code to download and decode the data returned by the URL below and didn’t get
an error. I am building against iOS 7.1 and I tried it out in the simulator.
Doing a brief search, it seems like when others are running into this error,
they’re working with JSON data that really does have garbage at the end. Is it
possible that you’re doing something like appending a null terminator or
something else non-printable so that when you look at the data then it all
seems OK?
On Apr 30, 2014, at 8:20 AM, Diederik Meijer | Ten Horses
wrote:
> Hi all,
>
> I have Googled this issue for hours and tried various solutions suggested at
> Stackoverflow, but can't seem to solve the following problem.
>
> I am pulling JSON from here:
> http://www.tenhorses.com/apps/meijburg/dotTAXDataHandler/dotTAXtaxNotesAPI.php
>
> Both JSONLint, http://jsonformatter.curiousconcept.com and freeformatter.com
> say this is valid JSON.
>
> I am using the NSURLConnection delegate methods (appending data as it comes
> in to a NSMutableData object) and are serialising the downloaded data in the
> didFinishLoading like so:
>
>NSError *error;
>id jsonObject = [NSJSONSerialization JSONObjectWithData:self.container
> options:NSJSONReadingAllowFragments error:&error];
>if (error) {
>NSLog(@"ERROR: %@", error);
>}
>else {
>if ([self.type isEqual:@"people"] || [self.type isEqual:@"projects"]
> || [self.type isEqual:@"taxNotes"]) jsonObject = [jsonObject
> objectForKey:@"items"];
>NSString *notificationName = [NSString
> stringWithFormat:@"%@DataDownloaded", self.type];
>[[NSNotificationCenter defaultCenter]
> postNotificationName:notificationName object:nil userInfo:[NSDictionary
> dictionaryWithObject:jsonObject forKey:@"jsonArray"]];
>[sharedConnectionList removeObject:self];
>}
>
>
> In short this sends off a notification with a pointer to an NSArray in case
> the downloader object's type is 'people', projects' or 'taxNotes' and to a
> NSDictionary in other cases.
>
> Now here is the problem: although the JSON parses fine and populates a
> UITableView without any issues, I am still getting the following error:
>
> Error Domain=NSCocoaErrorDomain Code=3840 "The operation couldn’t be
> completed. (Cocoa error 3840.)" (Garbage at end.) UserInfo=0xa2329a0
> {NSDebugDescription=Garbage at end.}
>
> I tested by creating an NSString from the data object and adding a few
> characters at the end. Never does that reveal anything that should be there
> at the end of the JSON string.
>
> This, in itself, is slightly unsettling, but not critically wrong..
>
> Has anybody here experienced a similar issue?
>
> If so, can you tell me how to fix this?
>
> Many thanks,
>
> Diederik
___
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: Problem with distributed objects in GUI cocoa apps
On Apr 30, 2014, at 11:19 AM, Costas Chatzinikolas wrote: > So if i want to create two apps (one for Mac OS X - one for iOS) that speak > to each other, > i have to use sockets. Am i correct? Yes. DO between computers (over TCP) was never really supported on OS X, and has a number of security and reliability problems that would make it a really bad idea for any real-world use. (I know, because I tried to do that once.) And AFAIK, XPC is purely intra-computer. (Frankly, _any_ API for networked communication that tries to make network calls look just like regular function calls is a bad idea. Distributed and local computing are very, very different, and papering over the differences will lead the client code straight into the well-known fallacies of distributed computing*.) I have a framework called MYNetwork** that provides a fairly clean high-level API for letting two apps talk to each other. People have been using WebSockets lately too, but to my knowledge there aren’t any really good WebSocket client and server libraries for Cocoa yet. —Jens * http://en.wikipedia.org/wiki/Fallacies_of_Distributed_Computing ** https://github.com/snej/mynetwork ___ 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: JSONSerialization 'Garbage at end' error
On Apr 30, 2014, at 12:14 PM, Steve Christensen wrote: > Doing a brief search, it seems like when others are running into this error, > they’re working with JSON data that really does have garbage at the end. Yeah, I’ve been doing a ton of JSON work with NSJSONSerialization for as long as it’s been available, and the only time I’ve ever seen that error was when the JSON really was corrupted. —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: JSONSerialization 'Garbage at end' error
On Apr 30, 2014, at 3:21 PM, Jens Alfke wrote: > You’ll need to do some detective work to find out what function call that > error is really coming from. At that point you can set a breakpoint and look > at the input data. Maybe for debugging purposes you could drop in an open-source JSON parser and see if you still get an error. If so, it'd be easier to figure out where to put the breakpoint. --Andy ___ 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: Problem with distributed objects in GUI cocoa apps
On Apr 30, 2014, at 2:39 PM, Jens Alfke wrote: > Yes. DO between computers (over TCP) was never really supported on OS X, It most certainly was supported, and useable on a LAN (and even on a WAN over VPN, did not try it in the wild). > and has a number of security and reliability problems True. > that would make it a really bad idea for any real-world use. For the right context (non-mission critical convenience functionality, for example on top of zero-conf service discovery) it was (is?) a useable solution. Gerd ___ 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: JSONSerialization 'Garbage at end' error
On Apr 30, 2014, at 3:21 PM, Jens Alfke wrote:
> On Apr 30, 2014, at 8:20 AM, Diederik Meijer | Ten Horses
> wrote:
>
>> Now here is the problem: although the JSON parses fine and populates a
>> UITableView without any issues, I am still getting the following error:
>
> If the JSON parsed fine, then the error must be coming from somewhere else. A
> call to JSONObjectWithData: either returns a parsed object, or returns nil
> and sets the error. It doesn’t do both :)
Which means...
>NSError *error;
>id jsonObject = [NSJSONSerialization JSONObjectWithData:self.container
> options:NSJSONReadingAllowFragments error:&error];
>if (error) {
>NSLog(@"ERROR: %@", error);
>}
>else {
...you shouldn't be testing error, you should be checking whether jsonObject is
nil, and only then look at the error. Doing it the wrong way around could
explain false errors. For example, NSJSONSerialization could pessimistically
stick an error object in there as the default error, but manage to parse
successfully and return a non-nil object. But then I'm not sure how you could
*also* be having your table populated with the right objects.
--Andy
___
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: JSONSerialization 'Garbage at end' error
Thanks Steve, that's promising, most likely something wrong in my
NSURLConnection code then, or the way I call it.
I don't think there's anything trailing in the JSON content, there really
isn'tt much in there his is the api server code:
format('d.m.Y');
$Hyperlink = $row['hyperlink'];
$Title = $row['title'];
$PictureURL = $row['pictureUrl'];
$Note = array(
"username" => $UserName,
"dossiername" => $DossierName,
"text" => $Text,
"date" => $Date,
"link" => $Hyperlink,
"title" => $Title,
"pictureUrl" => $PictureURL
);
array_push($TaxNotes, $Note);
}
$object = new stdClass();
$object->items = $TaxNotes;
echo json_encode($object);
?>
Op Apr 30, 2014, om 9:14 PM heeft Steve Christensen het
volgende geschreven:
> I’m already doing downloads in my app using NSURLSession so I used my
> existing code to download and decode the data returned by the URL below and
> didn’t get an error. I am building against iOS 7.1 and I tried it out in the
> simulator.
>
> Doing a brief search, it seems like when others are running into this error,
> they’re working with JSON data that really does have garbage at the end. Is
> it possible that you’re doing something like appending a null terminator or
> something else non-printable so that when you look at the data then it all
> seems OK?
>
>
> On Apr 30, 2014, at 8:20 AM, Diederik Meijer | Ten Horses
> wrote:
>
>> Hi all,
>>
>> I have Googled this issue for hours and tried various solutions suggested at
>> Stackoverflow, but can't seem to solve the following problem.
>>
>> I am pulling JSON from here:
>> http://www.tenhorses.com/apps/meijburg/dotTAXDataHandler/dotTAXtaxNotesAPI.php
>>
>> Both JSONLint, http://jsonformatter.curiousconcept.com and freeformatter.com
>> say this is valid JSON.
>>
>> I am using the NSURLConnection delegate methods (appending data as it comes
>> in to a NSMutableData object) and are serialising the downloaded data in
>> the didFinishLoading like so:
>>
>> NSError *error;
>> id jsonObject = [NSJSONSerialization JSONObjectWithData:self.container
>> options:NSJSONReadingAllowFragments error:&error];
>> if (error) {
>> NSLog(@"ERROR: %@", error);
>> }
>> else {
>> if ([self.type isEqual:@"people"] || [self.type isEqual:@"projects"]
>> || [self.type isEqual:@"taxNotes"]) jsonObject = [jsonObject
>> objectForKey:@"items"];
>> NSString *notificationName = [NSString
>> stringWithFormat:@"%@DataDownloaded", self.type];
>> [[NSNotificationCenter defaultCenter]
>> postNotificationName:notificationName object:nil userInfo:[NSDictionary
>> dictionaryWithObject:jsonObject forKey:@"jsonArray"]];
>> [sharedConnectionList removeObject:self];
>> }
>>
>>
>> In short this sends off a notification with a pointer to an NSArray in case
>> the downloader object's type is 'people', projects' or 'taxNotes' and to a
>> NSDictionary in other cases.
>>
>> Now here is the problem: although the JSON parses fine and populates a
>> UITableView without any issues, I am still getting the following error:
>>
>> Error Domain=NSCocoaErrorDomain Code=3840 "The operation couldn’t be
>> completed. (Cocoa error 3840.)" (Garbage at end.) UserInfo=0xa2329a0
>> {NSDebugDescription=Garbage at end.}
>>
>> I tested by creating an NSString from the data object and adding a few
>> characters at the end. Never does that reveal anything that should be there
>> at the end of the JSON string.
>>
>> This, in itself, is slightly unsettling, but not critically wrong..
>>
>> Has anybody here experienced a similar issue?
>>
>> If so, can you tell me how to fix this?
>>
>> Many thanks,
>>
>> Diederik
>
>
___
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: JSONSerialization 'Garbage at end' error
Thanks Andy and Jens!
Op Apr 30, 2014, om 10:07 PM heeft Andy Lee het volgende
geschreven:
> On Apr 30, 2014, at 3:21 PM, Jens Alfke wrote:
>> On Apr 30, 2014, at 8:20 AM, Diederik Meijer | Ten Horses
>> wrote:
>>
>>> Now here is the problem: although the JSON parses fine and populates a
>>> UITableView without any issues, I am still getting the following error:
>>
>> If the JSON parsed fine, then the error must be coming from somewhere else.
>> A call to JSONObjectWithData: either returns a parsed object, or returns nil
>> and sets the error. It doesn’t do both :)
>
> Which means...
>
>> NSError *error;
>> id jsonObject = [NSJSONSerialization JSONObjectWithData:self.container
>> options:NSJSONReadingAllowFragments error:&error];
>> if (error) {
>> NSLog(@"ERROR: %@", error);
>> }
>> else {
>
> ...you shouldn't be testing error, you should be checking whether jsonObject
> is nil, and only then look at the error. Doing it the wrong way around could
> explain false errors. For example, NSJSONSerialization could pessimistically
> stick an error object in there as the default error, but manage to parse
> successfully and return a non-nil object. But then I'm not sure how you
> could *also* be having your table populated with the right objects.
>
> --Andy
>
>
___
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: JSONSerialization 'Garbage at end' error
I also find that it is good practice to set variables returned by reference to
nil before passing them.
NSError *error = nil;
Otherwise, they will contain garbage, and cannot reliably be tested to see if
the value was set. Andy is right though, that it is better to test whether
jsonObject is nil in this case.
Thanks,
Jon
On Apr 30, 2014, at 1:07 PM, Andy Lee wrote:
> On Apr 30, 2014, at 3:21 PM, Jens Alfke wrote:
>> On Apr 30, 2014, at 8:20 AM, Diederik Meijer | Ten Horses
>> wrote:
>>
>>> Now here is the problem: although the JSON parses fine and populates a
>>> UITableView without any issues, I am still getting the following error:
>>
>> If the JSON parsed fine, then the error must be coming from somewhere else.
>> A call to JSONObjectWithData: either returns a parsed object, or returns nil
>> and sets the error. It doesn’t do both :)
>
> Which means...
>
>> NSError *error;
>> id jsonObject = [NSJSONSerialization JSONObjectWithData:self.container
>> options:NSJSONReadingAllowFragments error:&error];
>> if (error) {
>> NSLog(@"ERROR: %@", error);
>> }
>> else {
>
> ...you shouldn't be testing error, you should be checking whether jsonObject
> is nil, and only then look at the error. Doing it the wrong way around could
> explain false errors. For example, NSJSONSerialization could pessimistically
> stick an error object in there as the default error, but manage to parse
> successfully and return a non-nil object. But then I'm not sure how you
> could *also* be having your table populated with the right objects.
>
> --Andy
>
>
> ___
>
> 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/jhull%40gbis.com
>
> This email sent to jh...@gbis.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: JSONSerialization 'Garbage at end' error
On Apr 30, 2014, at 16:00 , Jonathan Hull wrote: > I also find that it is good practice to set variables returned by reference > to nil before passing them. > > NSError *error = nil; > > Otherwise, they will contain garbage, and cannot reliably be tested to see if > the value was set. This point comes up every few months, and what you say isn’t technically correct. It doesn’t do anything useful to set a NSError* value returned via reference to nil before the method invocation. According to the particular pattern in use here, if the method succeeds, there’s no valid value returned for the NSError*. In this case, the value may have changed from the value before the call. The changed value is garbage, from the caller’s point of view. It is *not safe* to test ‘error’ on a successful return, regardless of how you initialize it. ___ 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: JSONSerialization 'Garbage at end' error
On Apr 30, 2014, at 4:00 PM, Jonathan Hull wrote: > I also find that it is good practice to set variables returned by reference > to nil before passing them. > NSError *error = nil; > Otherwise, they will contain garbage, and cannot reliably be tested to see if > the value was set. That’s still not a good idea. If the call succeeds, it’s not guaranteed that the error value is unchanged. It might have been set to some intermediate error value, for example. If the call failed, the error will contain a valid value whether or not you initialized the variable, so there’s no need to initialize it. tl;dr: NEVER use the error value to determine whether or not the call succeeded. Use the return value for that. Only look at the error if the return value told you the call failed. —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: JSONSerialization 'Garbage at end' error
On Wed, Apr 30, 2014, at 04:30 PM, Jens Alfke wrote: > > On Apr 30, 2014, at 4:00 PM, Jonathan Hull wrote: > > > I also find that it is good practice to set variables returned by reference > > to nil before passing them. > > NSError *error = nil; > > Otherwise, they will contain garbage, and cannot reliably be tested to see > > if the value was set. > > That’s still not a good idea. If the call succeeds, it’s not guaranteed > that the error value is unchanged. It might have been set to some > intermediate error value, for example. > If the call failed, the error will contain a valid value whether or not > you initialized the variable, so there’s no need to initialize it. > > tl;dr: NEVER use the error value to determine whether or not the call > succeeded. Use the return value for that. Only look at the error if the > return value told you the call failed. FWIW, there is at least one Apple API that requires you to check the error rather than the return value. All Apple APIs should now be leaving the error parameter alone in success cases. And with ARC, all object pointers are initialized to nil, even local variables. --Kyle Sluder ___ 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: Problem with distributed objects in GUI cocoa apps
If you are targeting at remote procedure calling across Internet I have a library CGIJSONObjects that wraps REST-style JSON-based HTTP remote calls into objects. Server side language is not important. I used it to interface a server using Java servlets. Sent from my iPhone > On May 1, 2014, at 4:04 AM, Gerd Knops wrote: > > >> On Apr 30, 2014, at 2:39 PM, Jens Alfke wrote: >> >> Yes. DO between computers (over TCP) was never really supported on OS X, > > It most certainly was supported, and useable on a LAN (and even on a WAN over > VPN, did not try it in the wild). > >> and has a number of security and reliability problems > > True. > >> that would make it a really bad idea for any real-world use. > > For the right context (non-mission critical convenience functionality, for > example on top of zero-conf service discovery) it was (is?) a useable > solution. > > Gerd > > > ___ > > 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/xcvista%40me.com > > This email sent to xcvi...@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: Problem with distributed objects in GUI cocoa apps
I am just experimenting with networking. I am trying to build small apps to get the inside. I firtsly thougth that Distributed Objects and remote procedure calling was the more elegant way to communicate over a LAN. Then i found that Distributed Objects won't work on iOS. I am still in the search before starting my next small epxriment app. And your opinions and experience are very valuable to me. Thanks a lot !!! 2014-05-01 7:25 GMT+03:00 ChanMaxthon : > If you are targeting at remote procedure calling across Internet I have a > library CGIJSONObjects that wraps REST-style JSON-based HTTP remote calls > into objects. Server side language is not important. I used it to interface > a server using Java servlets. > > Sent from my iPhone > > > On May 1, 2014, at 4:04 AM, Gerd Knops > wrote: > > > > > >> On Apr 30, 2014, at 2:39 PM, Jens Alfke wrote: > >> > >> Yes. DO between computers (over TCP) was never really supported on OS X, > > > > It most certainly was supported, and useable on a LAN (and even on a WAN > over VPN, did not try it in the wild). > > > >> and has a number of security and reliability problems > > > > True. > > > >> that would make it a really bad idea for any real-world use. > > > > For the right context (non-mission critical convenience functionality, > for example on top of zero-conf service discovery) it was (is?) a useable > solution. > > > > Gerd > > > > > > ___ > > > > 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/xcvista%40me.com > > > > This email sent to xcvi...@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/costas.chatzinikolas%40gmail.com > > This email sent to costas.chatziniko...@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
