From susan.cudmore at gmail.com Wed Jun 18 08:17:49 2014 From: susan.cudmore at gmail.com (Susan Cudmore) Date: Wed, 18 Jun 2014 08:17:49 -0400 Subject: CoreData error References: <4DE9D0E2-4C10-47C9-94DF-6E1B4346BC21@qfactor.com> Message-ID: <532A1D44-E636-4D4B-874F-F8CA6289C393@gmail.com> Hi All, I?m getting desperate here, and wondering if you all can suggest some other places for me to look or things to try. I?ve been Googling for the errors listed below, but without any luck. I am able to save records to Entity1 where the relationship field is nil. But when I try to save any number of Entity2 objects connected by the relationship, I get the save error listed below. I think my paths are correct when it comes to setting up the persistent store and the moc. Thanks for any thoughts you might have! /Sue My core data entities look like (with better names of course): Entity1 value1 value1 relationshipToEntity2 (one to many, optional) Entity2 value1 value2 relationshipToEntity1 (one to one) > Error saving event: Error Domain=NSCocoaErrorDomain Code=134030 "The operation couldn?t be completed. (Cocoa error 134030.)" UserInfo=0xc96b990 {NSAffectedStoresErrorKey=( > " (URL:file:///Users/scudmore/Library/Application%20Support/iPhone%20Simulator/7.1/Library/Documentation/qfactor/QFDataPlatform.sqlite)" > ), NSUnderlyingError=0xc9661c0 "The operation couldn?t be completed. (Cocoa error 4.)", NSFilePath=/Users/scudmore/Library/Application Support/iPhone Simulator/7.1/Library/Documentation/qfactor/QFDataPlatform.sqlite} > { > NSAffectedStoresErrorKey = ( > " (URL:file:///Users/scudmore/Library/Application%20Support/iPhone%20Simulator/7.1/Library/Documentation/qfactor/QFDataPlatform.sqlite)" > ); > NSFilePath = "/Users/scudmore/Library/Application Support/iPhone Simulator/7.1/Library/Documentation/qfactor/QFDataPlatform.sqlite"; > NSUnderlyingError = "Error Domain=NSCocoaErrorDomain Code=4 \"The operation couldn\U2019t be completed. (Cocoa error 4.)\" UserInfo=0xc9682b0 {NSUnderlyingError=0xc968290 \"The operation couldn\U2019t be completed. No such file or directory\"}"; > } > 2014-06-18 08:00:03.605 xctest[89344:303] Error reporting event session.start -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at johncshockey.com Wed Jun 18 08:56:36 2014 From: john at johncshockey.com (John Shockey) Date: Wed, 18 Jun 2014 05:56:36 -0700 Subject: CoreData error Message-ID: <1403096196.29213.130160981.076A79D9@webmail.messagingengine.com> Susan, Oh. That URL is not within the sandbox. It probably can't write there. Look at the code that is generating the document URL. John From john at johncshockey.com Wed Jun 18 08:52:41 2014 From: john at johncshockey.com (John Shockey) Date: Wed, 18 Jun 2014 05:52:41 -0700 Subject: CoreData error Message-ID: <1403095961.28210.130154957.6BDCB769@webmail.messagingengine.com> Susan, More information might help. Things I note: The URL in the error is a bit odd looking. Some of that's just getting to the simulator's data, but then it's in "Library/Documentation"? I'm working on a Mac project now, but that's not where the data for my last iPhone project lived. It was at: /Users/jcs/Library/Application\ Support/iPhone\ Simulator/7.0.3/Applications/DD1F8EB8-A291-47BE-8343-2CD0C4C5DAFD/Documents/MudWatt_Explorer.sqlite I'm not sure what that means, but... I also note that the relationship from Entity2 doesn't say it's optional. Do you have a legitimate Entity1, and are you setting the link from your Entity 2's? Beyond that, seeing more of the code might help. Good luck. John From susan.cudmore at gmail.com Wed Jun 18 09:33:53 2014 From: susan.cudmore at gmail.com (Susan Cudmore) Date: Wed, 18 Jun 2014 09:33:53 -0400 Subject: CoreData error In-Reply-To: References: <1403095961.28210.130154957.6BDCB769@webmail.messagingengine.com> Message-ID: <5062D7E8-E59A-46B0-839F-567A2BF509D1@gmail.com> Thanks soooooo much. Just got to work and will check it out! I knew I could count on you all! /Sue > On Jun 18, 2014, at 9:20 AM, "T.J. Usiyan" wrote: > > Ah John has it. > NSDocumentDirectory vs NSDocumentationDirectory > > > > > >> On Wed, Jun 18, 2014 at 8:52 AM, John Shockey wrote: >> Susan, >> >> More information might help. >> >> Things I note: >> >> The URL in the error is a bit odd looking. Some of that's just getting >> to the simulator's data, but then it's in "Library/Documentation"? I'm >> working on a Mac project now, but that's not where the data for my last >> iPhone project lived. It was at: >> >> /Users/jcs/Library/Application\ Support/iPhone\ >> Simulator/7.0.3/Applications/DD1F8EB8-A291-47BE-8343-2CD0C4C5DAFD/Documents/MudWatt_Explorer.sqlite >> >> I'm not sure what that means, but... >> >> I also note that the relationship from Entity2 doesn't say it's >> optional. Do you have a legitimate Entity1, and are you setting the link >> from your Entity 2's? >> >> Beyond that, seeing more of the code might help. >> >> Good luck. >> >> John >> _______________________________________________ >> MacTechGroup-discuss mailing list >> MacTechGroup-discuss at lists.mactechgroup.org >> http://lists.mactechgroup.org/mailman/listinfo/mactechgroup-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at johncshockey.com Wed Jun 18 09:42:07 2014 From: john at johncshockey.com (John Shockey) Date: Wed, 18 Jun 2014 06:42:07 -0700 Subject: Hello (was Re: CoreData error) Message-ID: <1403098927.7886.130177953.7D8BF42F@webmail.messagingengine.com> T.J.! How are you? I understand you moved away. I hope they're treating you well out there. Be well. John From griotspeak at gmail.com Wed Jun 18 09:20:47 2014 From: griotspeak at gmail.com (T.J. Usiyan) Date: Wed, 18 Jun 2014 09:20:47 -0400 Subject: CoreData error In-Reply-To: <1403095961.28210.130154957.6BDCB769@webmail.messagingengine.com> References: <1403095961.28210.130154957.6BDCB769@webmail.messagingengine.com> Message-ID: Ah John has it. NSDocumentDirectory vs NSDocumentationDirectory On Wed, Jun 18, 2014 at 8:52 AM, John Shockey wrote: > Susan, > > More information might help. > > Things I note: > > The URL in the error is a bit odd looking. Some of that's just getting > to the simulator's data, but then it's in "Library/Documentation"? I'm > working on a Mac project now, but that's not where the data for my last > iPhone project lived. It was at: > > /Users/jcs/Library/Application\ Support/iPhone\ > > Simulator/7.0.3/Applications/DD1F8EB8-A291-47BE-8343-2CD0C4C5DAFD/Documents/MudWatt_Explorer.sqlite > > I'm not sure what that means, but... > > I also note that the relationship from Entity2 doesn't say it's > optional. Do you have a legitimate Entity1, and are you setting the link > from your Entity 2's? > > Beyond that, seeing more of the code might help. > > Good luck. > > John > _______________________________________________ > MacTechGroup-discuss mailing list > MacTechGroup-discuss at lists.mactechgroup.org > http://lists.mactechgroup.org/mailman/listinfo/mactechgroup-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From susan.cudmore at gmail.com Wed Jun 18 09:57:51 2014 From: susan.cudmore at gmail.com (Susan Cudmore) Date: Wed, 18 Jun 2014 09:57:51 -0400 Subject: CoreData error In-Reply-To: References: <1403095961.28210.130154957.6BDCB769@webmail.messagingengine.com> Message-ID: <86718524-6ACD-404A-84E7-9D6FC7D8F7F9@gmail.com> Sure enough, that solved it! Thanks again! /Sue > On Jun 18, 2014, at 9:20 AM, "T.J. Usiyan" wrote: > > Ah John has it. > NSDocumentDirectory vs NSDocumentationDirectory > > > > > >> On Wed, Jun 18, 2014 at 8:52 AM, John Shockey wrote: >> Susan, >> >> More information might help. >> >> Things I note: >> >> The URL in the error is a bit odd looking. Some of that's just getting >> to the simulator's data, but then it's in "Library/Documentation"? I'm >> working on a Mac project now, but that's not where the data for my last >> iPhone project lived. It was at: >> >> /Users/jcs/Library/Application\ Support/iPhone\ >> Simulator/7.0.3/Applications/DD1F8EB8-A291-47BE-8343-2CD0C4C5DAFD/Documents/MudWatt_Explorer.sqlite >> >> I'm not sure what that means, but... >> >> I also note that the relationship from Entity2 doesn't say it's >> optional. Do you have a legitimate Entity1, and are you setting the link >> from your Entity 2's? >> >> Beyond that, seeing more of the code might help. >> >> Good luck. >> >> John >> _______________________________________________ >> MacTechGroup-discuss mailing list >> MacTechGroup-discuss at lists.mactechgroup.org >> http://lists.mactechgroup.org/mailman/listinfo/mactechgroup-discuss > -------------- next part -------------- An HTML attachment was scrubbed... URL: From owen at clipboardinc.com Wed Jun 18 10:00:14 2014 From: owen at clipboardinc.com (Owen Hartnett) Date: Wed, 18 Jun 2014 10:00:14 -0400 Subject: CoreData error In-Reply-To: <5062D7E8-E59A-46B0-839F-567A2BF509D1@gmail.com> References: <1403095961.28210.130154957.6BDCB769@webmail.messagingengine.com> <5062D7E8-E59A-46B0-839F-567A2BF509D1@gmail.com> Message-ID: <223A1E23-860B-4434-B0BE-916436011841@clipboardinc.com> Good catch John. Subtle enough that most people, like me, would have missed it. TJ, great to hear from you. Hope you are doing well wherever you went to. -Owen On Jun 18, 2014, at 9:33 AM, Susan Cudmore wrote: > Thanks soooooo much. Just got to work and will check it out! I knew I could count on you all! > > /Sue > > > On Jun 18, 2014, at 9:20 AM, "T.J. Usiyan" wrote: > >> Ah John has it. >> NSDocumentDirectory vs NSDocumentationDirectory >> >> >> >> >> On Wed, Jun 18, 2014 at 8:52 AM, John Shockey wrote: >> Susan, >> >> More information might help. >> >> Things I note: >> >> The URL in the error is a bit odd looking. Some of that's just getting >> to the simulator's data, but then it's in "Library/Documentation"? I'm >> working on a Mac project now, but that's not where the data for my last >> iPhone project lived. It was at: >> >> /Users/jcs/Library/Application\ Support/iPhone\ >> Simulator/7.0.3/Applications/DD1F8EB8-A291-47BE-8343-2CD0C4C5DAFD/Documents/MudWatt_Explorer.sqlite >> >> I'm not sure what that means, but... >> >> I also note that the relationship from Entity2 doesn't say it's >> optional. Do you have a legitimate Entity1, and are you setting the link >> from your Entity 2's? >> >> Beyond that, seeing more of the code might help. >> >> Good luck. >> >> John >> _______________________________________________ >> MacTechGroup-discuss mailing list >> MacTechGroup-discuss at lists.mactechgroup.org >> http://lists.mactechgroup.org/mailman/listinfo/mactechgroup-discuss >> > _______________________________________________ > MacTechGroup-discuss mailing list > MacTechGroup-discuss at lists.mactechgroup.org > http://lists.mactechgroup.org/mailman/listinfo/mactechgroup-discuss -------------- next part -------------- An HTML attachment was scrubbed... URL: From griotspeak at gmail.com Wed Jun 18 08:29:31 2014 From: griotspeak at gmail.com (T.J. Usiyan) Date: Wed, 18 Jun 2014 08:29:31 -0400 Subject: CoreData error In-Reply-To: <532A1D44-E636-4D4B-874F-F8CA6289C393@gmail.com> References: <4DE9D0E2-4C10-47C9-94DF-6E1B4346BC21@qfactor.com> <532A1D44-E636-4D4B-874F-F8CA6289C393@gmail.com> Message-ID: It looks like core data is trying to delete something that (doesn't exist|can't be deleted). Does one of the entities have a property that is a file with a nil default value? I don't really see how what you described would trigger this problem but? that's my best guess. TJ On Wed, Jun 18, 2014 at 8:17 AM, Susan Cudmore wrote: > > Hi All, > > I?m getting desperate here, and wondering if you all can suggest some > other places for me to look or things to try. I?ve been Googling for the > errors listed below, but without any luck. I am able to save records to > Entity1 where the relationship field is nil. But when I try to save any > number of Entity2 objects connected by the relationship, I get the save > error listed below. > > I think my paths are correct when it comes to setting up the persistent > store and the moc. > > Thanks for any thoughts you might have! > > /Sue > > > > My core data entities look like (with better names of course): > > Entity1 > > value1 > value1 > relationshipToEntity2 (one to many, optional) > > > Entity2 > > value1 > value2 > relationshipToEntity1 (one to one) > > > > * Error saving event: Error Domain=NSCocoaErrorDomain Code=134030 "The > operation couldn?t be completed. (Cocoa error 134030.)" UserInfo=0xc96b990 > {NSAffectedStoresErrorKey=(* > * " > (URL:file:///Users/scudmore/Library/Application%20Support/iPhone%20Simulator/7.1/Library/Documentation/qfactor/QFDataPlatform.sqlite)"* > *), NSUnderlyingError=0xc9661c0 "The operation couldn?t be completed. > (Cocoa error 4.)", NSFilePath=/Users/scudmore/Library/Application > Support/iPhone > Simulator/7.1/Library/Documentation/qfactor/QFDataPlatform.sqlite} * > *{* > * NSAffectedStoresErrorKey = (* > * " > (URL:file:///Users/scudmore/Library/Application%20Support/iPhone%20Simulator/7.1/Library/Documentation/qfactor/QFDataPlatform.sqlite)"* > * );* > * NSFilePath = "/Users/scudmore/Library/Application Support/iPhone > Simulator/7.1/Library/Documentation/qfactor/QFDataPlatform.sqlite";* > * NSUnderlyingError = "Error Domain=NSCocoaErrorDomain Code=4 \"The > operation couldn\U2019t be completed. (Cocoa error 4.)\" UserInfo=0xc9682b0 > {NSUnderlyingError=0xc968290 \"The operation couldn\U2019t be completed. No > such file or directory\"}";* > *}* > *2014-06-18 08:00:03.605 xctest[89344:303] Error reporting event > session.start* > > > > _______________________________________________ > MacTechGroup-discuss mailing list > MacTechGroup-discuss at lists.mactechgroup.org > http://lists.mactechgroup.org/mailman/listinfo/mactechgroup-discuss > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From griotspeak at gmail.com Wed Jun 18 10:21:17 2014 From: griotspeak at gmail.com (T.J. Usiyan) Date: Wed, 18 Jun 2014 10:21:17 -0400 Subject: Hello (was Re: CoreData error) In-Reply-To: <1403098927.7886.130177953.7D8BF42F@webmail.messagingengine.com> References: <1403098927.7886.130177953.7D8BF42F@webmail.messagingengine.com> Message-ID: I'm doing well. Still with Big Nerd Ranch in Atlanta. Fun times especially with the swift announcement. How are you doing? TJ On Wed, Jun 18, 2014 at 9:42 AM, John Shockey wrote: > T.J.! > > How are you? I understand you moved away. I hope they're treating you > well out there. > > Be well. > > John > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at johncshockey.com Wed Jun 18 12:05:01 2014 From: john at johncshockey.com (John Shockey) Date: Wed, 18 Jun 2014 09:05:01 -0700 Subject: Hello (was Re: CoreData error) Message-ID: <1403107501.16005.130235233.5B6D213A@webmail.messagingengine.com> TJ, Big Nerd Ranch seems like a decent place for you. Lots of smart people there. They're lucky to have you. You're both smart yourself, and good with people. Are you specializing in anything in particular? Swift: Yes. Very interesting. Mostly I like it, though I still have more to do to understand it. I think they made a few significant mistakes that compromise their goal of safety, though. But even then I expect I will be using it. I'm doing well also. Contracting on a Mac project these days, for a change. (It's indirectly music related, too. Dealing with RF, to help the user set up wireless mics.) Be well. John I'm doing well. Still with Big Nerd Ranch in Atlanta. Fun times especially with the swift announcement. How are you doing? -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at johncshockey.com Wed Jun 18 12:24:16 2014 From: john at johncshockey.com (John Shockey) Date: Wed, 18 Jun 2014 09:24:16 -0700 Subject: CoreData error Message-ID: <1403108656.20943.130239953.0060E881@webmail.messagingengine.com> Owen, Thanks. I don't know how many folks are on this list. I don't think the ones I've heard from today need this, but here's a list of debugging tips. If it's an easy bug, just do whatever works. But if you're stuck, consider: 1. The most important debugging tool is your brain. 2. Look hard at all the information you gather. Don't worry so much about immediately finding the bug. Just look for anything that isn't what you expected. Try to understand it, and you may find the bug shows itself in the process. (That was the solution for today's bug.) 3. Try single stepping through your code. I often do this with new code, especially if it's at all complicated, even if no bugs have shown up. While stepping, follow rules 1 and 2. 4. If an API call doesn't behave the way you expect, don't be too quick to decide it's a bug in the API. Think as if you were implementing that API -- what information would you have available, and how could you make it work? 5. Multi-threading issues have their own rules. Treat them like a math problem and try to prove you code correct. Alternatively, treat it as a puzzle and look for an exception. This is more theoretical than most debugging. Multi-threading issues are difficult! 6. If a bug is really hard to reproduce (see especially #5), don't give up easily when it finally occurs. I've been known to leave my debugger stopped on a bug for a day. It's slow, but if it takes you days to make it happen it's often worth it. Anyone else have any favorites? John From susan.cudmore at gmail.com Wed Jun 18 12:58:46 2014 From: susan.cudmore at gmail.com (Susan Cudmore) Date: Wed, 18 Jun 2014 12:58:46 -0400 Subject: CoreData error In-Reply-To: <1403108656.20943.130239953.0060E881@webmail.messagingengine.com> References: <1403108656.20943.130239953.0060E881@webmail.messagingengine.com> Message-ID: <6C63E0D6-DEBC-4121-8467-397C0FFF85F5@gmail.com> Thanks for that list! /Sue > On Jun 18, 2014, at 12:24 PM, John Shockey wrote: > > Owen, > > Thanks. > > I don't know how many folks are on this list. I don't think the ones > I've heard from today need this, but here's a list of debugging tips. > > If it's an easy bug, just do whatever works. But if you're stuck, > consider: > > 1. The most important debugging tool is your brain. > > 2. Look hard at all the information you gather. Don't worry so much > about immediately finding the bug. Just look for anything that isn't > what you expected. Try to understand it, and you may find the bug shows > itself in the process. (That was the solution for today's bug.) > > 3. Try single stepping through your code. I often do this with new code, > especially if it's at all complicated, even if no bugs have shown up. > While stepping, follow rules 1 and 2. > > 4. If an API call doesn't behave the way you expect, don't be too quick > to decide it's a bug in the API. Think as if you were implementing that > API -- what information would you have available, and how could you make > it work? > > 5. Multi-threading issues have their own rules. Treat them like a math > problem and try to prove you code correct. Alternatively, treat it as a > puzzle and look for an exception. This is more theoretical than most > debugging. Multi-threading issues are difficult! > > 6. If a bug is really hard to reproduce (see especially #5), don't give > up easily when it finally occurs. I've been known to leave my debugger > stopped on a bug for a day. It's slow, but if it takes you days to make > it happen it's often worth it. > > > Anyone else have any favorites? > > John > _______________________________________________ > MacTechGroup-discuss mailing list > MacTechGroup-discuss at lists.mactechgroup.org > http://lists.mactechgroup.org/mailman/listinfo/mactechgroup-discuss From owen at clipboardinc.com Wed Jun 18 13:31:06 2014 From: owen at clipboardinc.com (Owen Hartnett) Date: Wed, 18 Jun 2014 13:31:06 -0400 Subject: CoreData error In-Reply-To: <1403108656.20943.130239953.0060E881@webmail.messagingengine.com> References: <1403108656.20943.130239953.0060E881@webmail.messagingengine.com> Message-ID: <1834349B-7804-4B3B-8996-310F8DDB1AB2@clipboardinc.com> Here's a piece of code I use a lot, particularly when I'm wrestling with UI annoyances that I can't seem to get quite straight: // useful debugging method - send it a view and it will log all subviews // can be called from the debugger - (void) viewAllSubviews:(UIView *) topView Indent:(NSString *) indent { for (UIView * theView in [topView subviews]){ NSLog(@"%@%@", indent, theView); if ([theView subviews] != nil) [self viewAllSubviews:theView Indent: [NSString stringWithFormat:@"%@ ",indent]]; } } I throw this in my AppDelegate so I can call it from anywhere. For the first parameter, just give it a parent view, and it will dump out indented all the subviews. Usage is (from the debugger): po [appDelegate viewAllSubviews:rootViewController.view Indent:@" "]; You can replace any parent view for rootViewController.view, and use whatever number of spaces you want to indent. I breakpoint and clear the console, and call it from the debugger, select all then copy and paste into a BBEdit window (or any text window). It displays a nice tree of my subviews and displays which frames are where, etc., better than stepping through them all. Another good tip, is that when the impossible is happening, your assumptions are wrong. The other day one of my colleagues spent a day on a nasty bug where he was moving a view around in response to a gesture. He saw the frame coordinates change in the debugger, but the view stayed in the same spot! Turns out he was changing the coordinates in a thread, and it needed to be done on the main thread (because it was graphics-related), but it's a good example of where the impossible (a view visibly in one place, but it's frame coordinates indicating another) is happening. -Owen On Jun 18, 2014, at 12:24 PM, John Shockey wrote: > Owen, > > Thanks. > > I don't know how many folks are on this list. I don't think the ones > I've heard from today need this, but here's a list of debugging tips. > > If it's an easy bug, just do whatever works. But if you're stuck, > consider: > > 1. The most important debugging tool is your brain. > > 2. Look hard at all the information you gather. Don't worry so much > about immediately finding the bug. Just look for anything that isn't > what you expected. Try to understand it, and you may find the bug shows > itself in the process. (That was the solution for today's bug.) > > 3. Try single stepping through your code. I often do this with new code, > especially if it's at all complicated, even if no bugs have shown up. > While stepping, follow rules 1 and 2. > > 4. If an API call doesn't behave the way you expect, don't be too quick > to decide it's a bug in the API. Think as if you were implementing that > API -- what information would you have available, and how could you make > it work? > > 5. Multi-threading issues have their own rules. Treat them like a math > problem and try to prove you code correct. Alternatively, treat it as a > puzzle and look for an exception. This is more theoretical than most > debugging. Multi-threading issues are difficult! > > 6. If a bug is really hard to reproduce (see especially #5), don't give > up easily when it finally occurs. I've been known to leave my debugger > stopped on a bug for a day. It's slow, but if it takes you days to make > it happen it's often worth it. > > > Anyone else have any favorites? > > John -------------- next part -------------- An HTML attachment was scrubbed... URL: From john at johncshockey.com Wed Jun 18 14:16:06 2014 From: john at johncshockey.com (John Shockey) Date: Wed, 18 Jun 2014 11:16:06 -0700 Subject: CoreData error Message-ID: <1403115366.18734.130284437.08CC9F63@webmail.messagingengine.com> Owen, I've written code like that myself, when I need some particular information. But it turns out there's already code like that built in. Which maybe leads to another tip: Read whichever is appropriate of the tech notes Technical Note TN2239 -- iOS Debugging Magic Technical Note TN2124 -- Mac OS X Debugging Magic (See the methods "recursiveDescription" in the first case, and "_subtreeDescription" in the second. They are not documented elsewhere.) John Here's a piece of code I use a lot, particularly when I'm wrestling with UI annoyances that I can't seem to get quite straight: // useful debugging method - send it a view and it will log all subviews // can be called from the debugger - (void) viewAllSubviews:(UIView *) topView Indent:(NSString *) indent { for (UIView * theView in [topView subviews]){ NSLog(@"%@%@", indent, theView); if ([theView subviews] != nil) [selfviewAllSubviews:theView Indent: [NSStringstringWithFormat:@"%@ ",indent]]; } } -------------- next part -------------- An HTML attachment was scrubbed... URL: