From rosenberg at acm.org Mon Jun 1 12:18:23 2015 From: rosenberg at acm.org (David M Rosenberg) Date: Mon, 1 Jun 2015 12:18:23 -0400 Subject: Help with a Swift OS X program In-Reply-To: References: <6290D078-46C0-41B1-8369-69BD0F9A78D4@acm.org> Message-ID: <655FD7D5-2BD6-4200-8B0D-54F6831587A1@acm.org> Hi Erik, Thank you for contacting me. So far you are the only one who has, so I?m very eager to be in touch with you. I?ve taken the current source code and shortened it by replacing a very long string literal with a short (junk) one, deleting most of the entries in a dictionary literal, and replacing the real URL with a fake one. I posted the source code at http://pastebin.com/HwNLxbi9 The program contains comments about the things that aren?t implemented yet. I haven?t implemented a user interface. (It uses NSOpenPanel and NSSavePanel to allow the user select the input and output files). Most immediately, I need help restructuring the use of NSURLSession as described in your message. Other issues will be figuring out why NSFileHandle is returning nil instead of a handle, setting up a window and updating the displayed counts of records processed in the window, and responding to clicks on two buttons (one of which I?d like to have change its name from Start to Pause to Resume, depending on what state the program is in and the other of which I?d like to have change its name from Quit to Finish, depending on what state the program is in). Do you expect to be at the MacTech group meeting this Wednesday? If so, could we talk then? Thanks very much for your response. /David > On Jun 1, 2015, at 10:50 AM, Erik Price wrote: > David, please disregard this if you've already gotten some help or solved your problem. > > Speaking for myself, and possibly for others, it's easier to evaluate whether I can help you if I can see the code you have so far. Do you (or can you) post that code to a public source code repository somewhere? > > At a high level, you are correct that NSURLSession is not designed to be used synchronously, and if you've written your code with the assumption that it works that way, you'll want to go back and rework things. Typically, you would either create a completion block or a class that conforms to the NSURLSessionDelegate protocol, and the NSURLSession will call you back with either of these facilities to let you know when data has been received. At that point, you can buffer the data in memory or write it to the output file. > > Good luck! From erikprice at gmail.com Mon Jun 1 10:50:50 2015 From: erikprice at gmail.com (Erik Price) Date: Mon, 1 Jun 2015 10:50:50 -0400 Subject: Help with a Swift OS X program In-Reply-To: <6290D078-46C0-41B1-8369-69BD0F9A78D4@acm.org> References: <6290D078-46C0-41B1-8369-69BD0F9A78D4@acm.org> Message-ID: David, please disregard this if you've already gotten some help or solved your problem. Speaking for myself, and possibly for others, it's easier to evaluate whether I can help you if I can see the code you have so far. Do you (or can you) post that code to a public source code repository somewhere? At a high level, you are correct that NSURLSession is not designed to be used synchronously, and if you've written your code with the assumption that it works that way, you'll want to go back and rework things. Typically, you would either create a completion block or a class that conforms to the NSURLSessionDelegate protocol, and the NSURLSession will call you back with either of these facilities to let you know when data has been received. At that point, you can buffer the data in memory or write it to the output file. Good luck! e On Sun, May 31, 2015 at 1:12 PM, David M Rosenberg wrote: > I'm trying to write an OSX program in Swift. The program performs what is > essentially a background function: reading a line from a tab-delimited > input file, extracting information from that line and formating it into the > body of an HTTP POST, executing the HTTP POST request, receiving the > response, manipulating it, writing it as the next line in a tab-delimited > output file, and looping back to read the next input line until we reach > the end of the input file. > > It could have almost been a command line program. I wanted to give it a > (minimal) user interface because I wanted the user to be able to browse the > file system to select the input and output files, to have "Pause" and > "Quit" buttons to control execution, to have a window in which to display > status of what the program was doing, and maybe to give the user a little > more control before starting the program (such as turning on debugging mode > or telling it to just validate the input without actually doing the HTTP > POST). I guess I also want the experience of writing a Swift program with a > user interface. > > I have written the part of the program that does the work of formating > input into the body of an HTTP POST, executing the HTTP POST request, > receiving the response, manipulating it, and formating it to be written to > the output file. The program doesn't have any user interface. It uses > NSOpenPanel and NSSavePanel to allow the user select the input and output > files, but at the moment I can't get it to actually read or write files. > But the biggest problem is that it is written in a very non-object-oriented > fashion. It basically has one large, synchronous "read, process, write" > loop. The program uses NSURLSession.sharedSession to do the HTTP POST. The > program wants to treat the HTTP POST as happening in the main loop and > being blocked until a response arrives. But that isn't what the system > wants to do. The system wants to run the NSURLSession in a separate > asynchronous task. I need help in synchronizing the NSURLSession with my > main loop. I'd also like to restructure the program to be object-oriented. > > I?m looking for someone who would be willing to provide some advice and > guidance - perhaps during the next MacTech group meeting, perhaps after the > meeting, perhaps on a separate occasion either in person, by phone or by > E-Mail. > > Please contact me if you might be willing to help. > > Thanks. > > /David > _______________________________________________ > 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 Tue Jun 2 07:53:42 2015 From: john at johncshockey.com (John Shockey) Date: Tue, 02 Jun 2015 04:53:42 -0700 Subject: Help with a Swift OS X program Message-ID: <1433246022.263258.284581609.4D560B86@webmail.messagingengine.com> David, My apologies for not getting back to you more quickly. I started a response, but I'm working under a deadline and it swallowed me up before I finished it. What I was working on was a bit longer, but what Erik said is correct, and along the same lines as I was writing. Just because it's important, I'll repeat a part of what he said: You should never attempt to do synchronous (blocking) programming, and synchronous network programming in particular, on the main thread. That leaves you at least three possibilities. 1. Move the networking to an alternate thread. I don't think this will be the best choice. Among other things, you'd need to use lower level APIs if you really want to do your networking synchronously. Plus, synchronizing between threads allows all sorts of things to go wrong. Sometimes it's worth it to use threads, but it's probably too much work. 2. Write a real command line utility, and a UI program that runs it in a separate process. There are times when this is a good approach, but it seems like way too much work in your situation. 3. Do your networking asynchronously. It's fairly simple once you understand how it works, and there's no need for explicit threading. (Though Cocoa may use threads behind the scenes, you won't have to deal with it.) You will need to rearrange how you're doing things, but learning to do it the was Cocoa intends should be worth the effort. Again, what Erik said is correct. I'm just a little more long-winded. If you want help figuring out how to use NSURLSession, feel free to bring your questions to a meeting. We don't have a specific presentation scheduled this month, so there should be plenty of time. If you can't make it to a meeting, and if Erik hasn't already helped you sufficiently, take a look at the documentation for NSURLSession and friends, and then ask again here. Good luck, John From steve.sisak at ioxperts.com Tue Jun 2 14:05:53 2015 From: steve.sisak at ioxperts.com (Steve Sisak) Date: Tue, 2 Jun 2015 14:05:53 -0400 Subject: Help with a Swift OS X program In-Reply-To: <1433246022.263258.284581609.4D560B86@webmail.messagingengine.com> References: <1433246022.263258.284581609.4D560B86@webmail.messagingengine.com> Message-ID: I just got back to Boston (2am) after a 9 hour drive and haven?t looked into the details, but if you want, I could probably throw together a session on NSURLSession and alternates and use this as an example. BTW, it ought to be pretty trivial to preserve the illusion of synchronicity using blocks and dispatch queues. Caveat: I?ve barely looked at Swift, so we?d have to meet in the middle. HTH, -Steve > On Jun 2, 2015, at 7:53 AM, John Shockey wrote: > > David, > > My apologies for not getting back to you more quickly. I started a > response, but I'm working under a deadline and it swallowed me up before > I finished it. > > What I was working on was a bit longer, but what Erik said is correct, > and along the same lines as I was writing. > > Just because it's important, I'll repeat a part of what he said: You > should never attempt to do synchronous (blocking) programming, and > synchronous network programming in particular, on the main thread. > > That leaves you at least three possibilities. > > 1. Move the networking to an alternate thread. I don't think this will > be the best choice. Among other things, you'd need to use lower level > APIs if you really want to do your networking synchronously. Plus, > synchronizing between threads allows all sorts of things to go wrong. > Sometimes it's worth it to use threads, but it's probably too much work. > > 2. Write a real command line utility, and a UI program that runs it in a > separate process. There are times when this is a good approach, but it > seems like way too much work in your situation. > > 3. Do your networking asynchronously. It's fairly simple once you > understand how it works, and there's no need for explicit threading. > (Though Cocoa may use threads behind the scenes, you won't have to deal > with it.) You will need to rearrange how you're doing things, but > learning to do it the was Cocoa intends should be worth the effort. > > Again, what Erik said is correct. I'm just a little more long-winded. > > > If you want help figuring out how to use NSURLSession, feel free to > bring your questions to a meeting. We don't have a specific presentation > scheduled this month, so there should be plenty of time. If you can't > make it to a meeting, and if Erik hasn't already helped you > sufficiently, take a look at the documentation for NSURLSession and > friends, and then ask again here. > > Good luck, > > John > > _______________________________________________ > MacTechGroup-discuss mailing list > MacTechGroup-discuss at lists.mactechgroup.org > http://lists.mactechgroup.org/mailman/listinfo/mactechgroup-discuss From erikprice at gmail.com Tue Jun 2 11:01:00 2015 From: erikprice at gmail.com (Erik Price) Date: Tue, 2 Jun 2015 11:01:00 -0400 Subject: Help with a Swift OS X program In-Reply-To: <655FD7D5-2BD6-4200-8B0D-54F6831587A1@acm.org> References: <6290D078-46C0-41B1-8369-69BD0F9A78D4@acm.org> <655FD7D5-2BD6-4200-8B0D-54F6831587A1@acm.org> Message-ID: Hi David, I've taken a look at the code you posted. You're right, it uses a very procedural approach, where the program starts at the top and continues to the bottom, much like a script. However, Cocoa programs seldom have this kind of structure. If you take a look at any of Apple's sample code, you'll see that most Mac programs actually consist of a number of functions, and often multiple classes. You might want to read through this Apple documentation introducing Mac app development, to get a sense for it: https://developer.apple.com/library/mac/referencelibrary/GettingStarted/RoadMapOSX/chapters/01_Introduction.html What I'd suggest is to create a brand new project (don't throw the current code away, since you can reuse most of it) and just make an app that shows a basic UI with an "open" button. Get it so that clicking the button opens the NSOpenPanel, then add another button for saving the output file and do the same thing with NSSavePanel. Once you have this basic skeleton in place, add the code to create a very basic NSURLSession (perhaps one that just requests the Google home page or something), and try setting a delegate or completion block on the NSURLSession. The delegate or block could just use NSLog to say "success" or something like that. Once you have those things working, gradually start migrating the code from your current project into the appropriate functions in the new project, until you have things working the way you want them to. I won't be at the meeting on Wednesday, so I apologize that I won't be able to help you in person. Perhaps there will be others who can. You can definitely get help for things like this at the Boston CocoaHeads meetings too (they meet second Thursday of every month). Or feel free to continue posting here if you have questions or run into any problems making progress. Good luck e On Mon, Jun 1, 2015 at 12:18 PM, David M Rosenberg wrote: > Hi Erik, > > Thank you for contacting me. So far you are the only one who has, so I?m > very eager to be in touch with you. > > I?ve taken the current source code and shortened it by replacing a very > long string literal with a short (junk) one, deleting most of the entries > in a dictionary literal, and replacing the real URL with a fake one. I > posted the source code at http://pastebin.com/HwNLxbi9 The program > contains comments about the things that aren?t implemented yet. I haven?t > implemented a user interface. (It uses NSOpenPanel and NSSavePanel to allow > the user select the input and output files). > > Most immediately, I need help restructuring the use of NSURLSession as > described in your message. Other issues will be figuring out why > NSFileHandle is returning nil instead of a handle, setting up a window and > updating the displayed counts of records processed in the window, and > responding to clicks on two buttons (one of which I?d like to have change > its name from Start to Pause to Resume, depending on what state the program > is in and the other of which I?d like to have change its name from Quit to > Finish, depending on what state the program is in). > > Do you expect to be at the MacTech group meeting this Wednesday? If so, > could we talk then? > > Thanks very much for your response. > > /David > > > On Jun 1, 2015, at 10:50 AM, Erik Price wrote: > > David, please disregard this if you've already gotten some help or > solved your problem. > > > > Speaking for myself, and possibly for others, it's easier to evaluate > whether I can help you if I can see the code you have so far. Do you (or > can you) post that code to a public source code repository somewhere? > > > > At a high level, you are correct that NSURLSession is not designed to be > used synchronously, and if you've written your code with the assumption > that it works that way, you'll want to go back and rework things. > Typically, you would either create a completion block or a class that > conforms to the NSURLSessionDelegate protocol, and the NSURLSession will > call you back with either of these facilities to let you know when data has > been received. At that point, you can buffer the data in memory or write it > to the output file. > > > > Good luck! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rosenberg at acm.org Wed Jun 3 01:42:45 2015 From: rosenberg at acm.org (David M Rosenberg) Date: Wed, 3 Jun 2015 01:42:45 -0400 Subject: Help with a Swift OS X program In-Reply-To: <1433246022.263258.284581609.4D560B86@webmail.messagingengine.com> References: <1433246022.263258.284581609.4D560B86@webmail.messagingengine.com> Message-ID: John, Erik, And Steve, Thank you for your responses, suggestions, and guidance. All three of you are suggesting that the program needs to be rewritten. I take it that John?s suggestion 3 below is what both Erik and Steve are suggesting. So that?s what I?d like to do. I?ve been doing development on an iMac that I can?t bring the to the meeting with me. I?m using Xcode 6.3.2 under OSX 10.10.3. I can copy the project folder (is that all I need?) to a flash drive and bring that with me to the MacTech group meeting. I hope it will be possible either during or after the meeting to put that on someone?s laptop and that someone will be able to show me how to crate a new project with the right kind of structure. I hope that with your help setting up an appropriate structure, I?ll be able to move my code into it and create a functioning program. You and Owen will have to tell me whether the sort of help I?m looking for is too elementary/boring/uninteresting/inappropriate to take up the time of the MacTech group meeting. If it is considered appropriate, I?d be happy to discuss what I?m trying to do, why I?m trying to do it, and what I?d like it to look like and hopefully leave the meeting with a reasonable structure that I can continue working on by myself. Thanks. /David > On Jun 2, 2015, at 7:53 AM, John Shockey wrote: > David, > > My apologies for not getting back to you more quickly. I started a > response, but I'm working under a deadline and it swallowed me up before > I finished it. > > What I was working on was a bit longer, but what Erik said is correct, > and along the same lines as I was writing. > > Just because it's important, I'll repeat a part of what he said: You > should never attempt to do synchronous (blocking) programming, and > synchronous network programming in particular, on the main thread. > > That leaves you at least three possibilities. > > 1. Move the networking to an alternate thread. I don't think this will > be the best choice. Among other things, you'd need to use lower level > APIs if you really want to do your networking synchronously. Plus, > synchronizing between threads allows all sorts of things to go wrong. > Sometimes it's worth it to use threads, but it's probably too much work. > > 2. Write a real command line utility, and a UI program that runs it in a > separate process. There are times when this is a good approach, but it > seems like way too much work in your situation. > > 3. Do your networking asynchronously. It's fairly simple once you > understand how it works, and there's no need for explicit threading. > (Though Cocoa may use threads behind the scenes, you won't have to deal > with it.) You will need to rearrange how you're doing things, but > learning to do it the was Cocoa intends should be worth the effort. > > Again, what Erik said is correct. I'm just a little more long-winded. > > > If you want help figuring out how to use NSURLSession, feel free to > bring your questions to a meeting. We don't have a specific presentation > scheduled this month, so there should be plenty of time. If you can't > make it to a meeting, and if Erik hasn't already helped you > sufficiently, take a look at the documentation for NSURLSession and > friends, and then ask again here. > > Good luck, > > John From john at johncshockey.com Wed Jun 3 08:00:04 2015 From: john at johncshockey.com (John Shockey) Date: Wed, 03 Jun 2015 05:00:04 -0700 Subject: Help with a Swift OS X program Message-ID: <1433332804.633954.285623225.2BF53C09@webmail.messagingengine.com> David, Yes, I think we're all saying essentially the same thing, just in different ways. By all means bring your questions, and your code, to the meeting. One way or another I hope we'll be able to help you. John From steve.sisak at ioxperts.com Wed Jun 3 15:51:49 2015 From: steve.sisak at ioxperts.com (Steve Sisak) Date: Wed, 3 Jun 2015 15:51:49 -0400 Subject: Help with a Swift OS X program In-Reply-To: References: <1433246022.263258.284581609.4D560B86@webmail.messagingengine.com> Message-ID: Hi Dave, Just copying the folder to a flash drive should work. Bring it and we?ll try to get it behaving better. I?m figuring we?ll take a couple passes though your code and get it working cleanly. I know the network side from Obj-C quite well ? we?ll count on you and the group to do the conversion to Swift. Does anyone remember what class of dongle I need for the projector for a MacBook Pro (Thunderbolt)? (DVI or VGA)? Thanks, -Steve > On Jun 3, 2015, at 1:42 AM, David M Rosenberg wrote: > > John, Erik, And Steve, > > Thank you for your responses, suggestions, and guidance. > > All three of you are suggesting that the program needs to be rewritten. I take it that John?s suggestion 3 below is what both Erik and Steve are suggesting. So that?s what I?d like to do. I?ve been doing development on an iMac that I can?t bring the to the meeting with me. I?m using Xcode 6.3.2 under OSX 10.10.3. I can copy the project folder (is that all I need?) to a flash drive and bring that with me to the MacTech group meeting. I hope it will be possible either during or after the meeting to put that on someone?s laptop and that someone will be able to show me how to crate a new project with the right kind of structure. I hope that with your help setting up an appropriate structure, I?ll be able to move my code into it and create a functioning program. > > You and Owen will have to tell me whether the sort of help I?m looking for is too elementary/boring/uninteresting/inappropriate to take up the time of the MacTech group meeting. If it is considered appropriate, I?d be happy to discuss what I?m trying to do, why I?m trying to do it, and what I?d like it to look like and hopefully leave the meeting with a reasonable structure that I can continue working on by myself. > > Thanks. > > /David > > >> On Jun 2, 2015, at 7:53 AM, John Shockey wrote: >> David, >> >> My apologies for not getting back to you more quickly. I started a >> response, but I'm working under a deadline and it swallowed me up before >> I finished it. >> >> What I was working on was a bit longer, but what Erik said is correct, >> and along the same lines as I was writing. >> >> Just because it's important, I'll repeat a part of what he said: You >> should never attempt to do synchronous (blocking) programming, and >> synchronous network programming in particular, on the main thread. >> >> That leaves you at least three possibilities. >> >> 1. Move the networking to an alternate thread. I don't think this will >> be the best choice. Among other things, you'd need to use lower level >> APIs if you really want to do your networking synchronously. Plus, >> synchronizing between threads allows all sorts of things to go wrong. >> Sometimes it's worth it to use threads, but it's probably too much work. >> >> 2. Write a real command line utility, and a UI program that runs it in a >> separate process. There are times when this is a good approach, but it >> seems like way too much work in your situation. >> >> 3. Do your networking asynchronously. It's fairly simple once you >> understand how it works, and there's no need for explicit threading. >> (Though Cocoa may use threads behind the scenes, you won't have to deal >> with it.) You will need to rearrange how you're doing things, but >> learning to do it the was Cocoa intends should be worth the effort. >> >> Again, what Erik said is correct. I'm just a little more long-winded. >> >> >> If you want help figuring out how to use NSURLSession, feel free to >> bring your questions to a meeting. We don't have a specific presentation >> scheduled this month, so there should be plenty of time. If you can't >> make it to a meeting, and if Erik hasn't already helped you >> sufficiently, take a look at the documentation for NSURLSession and >> friends, and then ask again here. >> >> Good luck, >> >> John From owen at clipboardinc.com Wed Jun 3 17:11:47 2015 From: owen at clipboardinc.com (Owen Hartnett) Date: Wed, 3 Jun 2015 17:11:47 -0400 Subject: Help with a Swift OS X program In-Reply-To: References: <1433246022.263258.284581609.4D560B86@webmail.messagingengine.com> Message-ID: <3B4103AC-8B1C-4A2E-84D3-83C8B9086A2A@clipboardinc.com> Depending on the room, you may not need one. There?s both HDMI and VGA in every room. Most of the time, there?s a display port/thunderbolt ->HDMI dongle in the room. If not a thunderbolt->VGA would do it I think. -Owen > On Jun 3, 2015, at 3:51 PM, Steve Sisak wrote: > > Hi Dave, > > Just copying the folder to a flash drive should work. Bring it and we?ll try to get it behaving better. > > I?m figuring we?ll take a couple passes though your code and get it working cleanly. > > I know the network side from Obj-C quite well ? we?ll count on you and the group to do the conversion to Swift. > > Does anyone remember what class of dongle I need for the projector for a MacBook Pro (Thunderbolt)? > > (DVI or VGA)? > > Thanks, > > -Steve > > >> On Jun 3, 2015, at 1:42 AM, David M Rosenberg wrote: >> >> John, Erik, And Steve, >> >> Thank you for your responses, suggestions, and guidance. >> >> All three of you are suggesting that the program needs to be rewritten. I take it that John?s suggestion 3 below is what both Erik and Steve are suggesting. So that?s what I?d like to do. I?ve been doing development on an iMac that I can?t bring the to the meeting with me. I?m using Xcode 6.3.2 under OSX 10.10.3. I can copy the project folder (is that all I need?) to a flash drive and bring that with me to the MacTech group meeting. I hope it will be possible either during or after the meeting to put that on someone?s laptop and that someone will be able to show me how to crate a new project with the right kind of structure. I hope that with your help setting up an appropriate structure, I?ll be able to move my code into it and create a functioning program. >> >> You and Owen will have to tell me whether the sort of help I?m looking for is too elementary/boring/uninteresting/inappropriate to take up the time of the MacTech group meeting. If it is considered appropriate, I?d be happy to discuss what I?m trying to do, why I?m trying to do it, and what I?d like it to look like and hopefully leave the meeting with a reasonable structure that I can continue working on by myself. >> >> Thanks. >> >> /David >> >> >>> On Jun 2, 2015, at 7:53 AM, John Shockey wrote: >>> David, >>> >>> My apologies for not getting back to you more quickly. I started a >>> response, but I'm working under a deadline and it swallowed me up before >>> I finished it. >>> >>> What I was working on was a bit longer, but what Erik said is correct, >>> and along the same lines as I was writing. >>> >>> Just because it's important, I'll repeat a part of what he said: You >>> should never attempt to do synchronous (blocking) programming, and >>> synchronous network programming in particular, on the main thread. >>> >>> That leaves you at least three possibilities. >>> >>> 1. Move the networking to an alternate thread. I don't think this will >>> be the best choice. Among other things, you'd need to use lower level >>> APIs if you really want to do your networking synchronously. Plus, >>> synchronizing between threads allows all sorts of things to go wrong. >>> Sometimes it's worth it to use threads, but it's probably too much work. >>> >>> 2. Write a real command line utility, and a UI program that runs it in a >>> separate process. There are times when this is a good approach, but it >>> seems like way too much work in your situation. >>> >>> 3. Do your networking asynchronously. It's fairly simple once you >>> understand how it works, and there's no need for explicit threading. >>> (Though Cocoa may use threads behind the scenes, you won't have to deal >>> with it.) You will need to rearrange how you're doing things, but >>> learning to do it the was Cocoa intends should be worth the effort. >>> >>> Again, what Erik said is correct. I'm just a little more long-winded. >>> >>> >>> If you want help figuring out how to use NSURLSession, feel free to >>> bring your questions to a meeting. We don't have a specific presentation >>> scheduled this month, so there should be plenty of time. If you can't >>> make it to a meeting, and if Erik hasn't already helped you >>> sufficiently, take a look at the documentation for NSURLSession and >>> friends, and then ask again here. >>> >>> Good luck, >>> >>> John >