Helping out with Swift 3 migrations
• Mark Eschbach
Just waiting for the pods to up date. The network on Amtrak is kind of slow today…hopefully I’m not like eating all the bandwidth for everyone else. Coming into a station, so perhaps we’ll get a speed boost! The refineries outside of Marteniz have a certain kind of industril pipe elegance to them. The grafiti on the retaining walls could use a little work though.
After the Pods finally installed I found the
Build/ directory contained a lot of cached information which was tripping Swift out, complaining about being compiled with the wrong version of Swift. After removing that directory the compiler could no longer find the bridging headers. Well, after a brief search it looks to be an issue with CocoaPods and Xcode not upgrading the projects. Let’s try that solution. Blown away, now just waiting for the installation process. Surprisingly not that slow for going through the north bay BART underground on a cellular network. Still missing the bridging headers, let’s see if the module imports are still an issue. Still no luck. Perhaps I’ve broken something unintentionally? Time to raise my hand. Nope, time to return to the issue at a later date.
Alrighty, returning to this task. Apprently the setting
buildImplicitDependencies=YES was the key. Good times. I wonder if there is a way for us to explicitly name dependencies, either in the file or through the command line. As apart of this migration we need to update our dependencies. One we couldn’t find a suitable alternative for was our logging to PaperTrail. As apart of this I’ve been assigned to finish out a library SwiftyPaperTrail for us. I’m picking up from tests not awaiting the draining of asynchronous operations. In other Swift tests I’ve manually created sync points because I’ve overlooked the the method
waitForExpectations/2. So the goal of the library is operate as the connective tissue between SwiftyLogger and the socket API for PaperTrail.
As of writing the state of the library is this: there are a set of tests which send information to PaperTrail but don’t verify that information is correctly pushed into the application. Underneath the hood the library uses CocoaAysncSocket to send data. I added a method to hook into the facade class
SwiftyPaperTrail to take a disconnection event. From here I need to boot up an in process service and verify the message was correctly sent. SwiftSocket looks like a promising library to verify the data was received in a simple and elegant way. I wrote the first half of the server to buffer the data, then realized it would probably be easier to use async sockets so I don’t have to dispatch a separate thread and deal with that. The general strategy I use with client and service applications of this nature is to boot up an in process mock when needing complex integrations to verify the correct data is written. The in-process service in this case boots on port 0, asking the networking stacks to allocate an address for us thus doing away with nasty time waits and such. We then query the listening socket for the bound port and connect there.
I’ve now automated the problem Majd had originally described to me yesterday: the client claims the data is written however the socket closes without transmitting the data. The serivce socket never receives any of the data. My hunch is the library doesn’t properly buffer the data possibly because OSX is accepting the write to buffer then discards. It’s over localhost now so we only have the delay of the network stack itself, possibly lower depending on the optimizations.