Hmm, it appears that in _my_ XCode7, at least, applicationDidBecomeActive is being called _before_ BrowserViewController.viewDidLoad and therefore the tab queue is being created (caused BrowserDB creation) before the history tables....
On 27 August 2015 at 14:51, Emily Toop <et...@mozilla.com> wrote: > Do we use this View: view_favicons_widest? > > I only ask as it's being created when the app starts, but before we've > invoked the HistoryTable which creates the favicons table, which is > referenced by the view, which causes the view creation to fail. I can't pin > down anything that has changed in this area that could affect the order in > which these things occur, as view_favicons_widest is created as part of > browser.db creation which always happens first. > > Can anyone spot what I am missing? > > > On 27 August 2015 at 14:20, Emily Toop <et...@mozilla.com> wrote: > >> That's what I'm doing. We can't even run the tests at the moment because >> the app crashes during initialisation. I'm working on getting that sorted >> so we can start running through the tests & resolving anything broken. >> >> I've added my name to the test suite that I intend to attack first in the >> mopad. >> >> On 27 August 2015 at 14:14, Stefan Arentz <sare...@mozilla.com> wrote: >> >>> Fantastic. So what is next? Do we keep working in the Swift-2.0 branch >>> until we can run the app on a device? >>> >>> S. >>> >>> >>> On Thu, Aug 27, 2015 at 5:45 AM, Emily Toop <et...@mozilla.com> wrote: >>> >>>> Today, is a Good Day. >>>> >>>> We have a cleanly compiling version of a Swift 2.0 port of FxiOS. >>>> >>>> Thank you everyone who helped out with this. >>>> >>>> Go forth and prosper my children. >>>> >>>> >>>> >>>> >>>> >>>> p.s. - now we just have to get it running 😕 >>>> >>>> On 26 August 2015 at 15:38, Stefan Arentz <sare...@mozilla.com> wrote: >>>> >>>>> This compiles: >>>>> >>>>> req.responseString(encoding: nil, completionHandler: { (a, b, >>>>> c) in >>>>> return handler(a, b, c.isSuccess ? >>>>> Result.Success(c.value!) : Result.Failure(c.data, c.error!)) >>>>> }) >>>>> >>>>> But the forced unwrapping feels wrong. >>>>> >>>>> S. >>>>> >>>>> >>>>> On Wed, Aug 26, 2015 at 10:33 AM, Stefan Arentz <sare...@mozilla.com> >>>>> wrote: >>>>> >>>>>> I narrowed it down to: >>>>>> >>>>>> // Yay Swift. >>>>>> let stringHandler = { (a, b, c: Result<String>) in >>>>>> return handler(a, b, c) >>>>>> } >>>>>> >>>>>> req.responseString(encoding: nil, completionHandler: >>>>>> stringHandler) >>>>>> >>>>>> Which is then changed to: >>>>>> >>>>>> req.responseString(encoding: nil, completionHandler: { (a, b, >>>>>> c) in >>>>>> return handler(a, b, c) >>>>>> }) >>>>>> >>>>>> but am now stuck on: >>>>>> >>>>>> StorageClient.swift:466:38: error: cannot convert value of >>>>>> type 'Result<String>' to expected argument type 'Result<AnyObject>' >>>>>> return handler(a, b, c) >>>>>> >>>>>> And I'm not sure what that means or how to resolve it. >>>>>> >>>>>> S. >>>>>> >>>>>> >>>>>> On Wed, Aug 26, 2015 at 1:29 AM, Brian Nicholson < >>>>>> bnichol...@mozilla.com> wrote: >>>>>> >>>>>>> I added some commits to the PR that fix the SchemaTable errors and >>>>>>> some other things, which then led to a number of errors in Sync. I think >>>>>>> those have all been fixed, though I'm now hitting a segfault in >>>>>>> StorageClient.swift, and the error isn't terribly helpful. >>>>>>> >>>>>>> Dump here: https://pastebin.mozilla.org/8843919 >>>>>>> >>>>>>> Not sure how many targets are left after this, but it does feel like >>>>>>> this is close to the end! >>>>>>> >>>>>>> On Tue, Aug 25, 2015 at 9:38 AM, Emily Toop <et...@mozilla.com> >>>>>>> wrote: >>>>>>> >>>>>>>> I feel I am really close to the end now with this port. >>>>>>>> >>>>>>>> I'm getting 2 errors around BrowserDB and the way we are declaring >>>>>>>> SchemaTable and that is all currently. When these clear, I guess we'll >>>>>>>> see >>>>>>>> if anything else pops up. If not, we just have to make sure it actually >>>>>>>> works. >>>>>>>> >>>>>>>> If anyone wants to look at this overnight, please, please go ahead. >>>>>>>> The sooner we get this done the better for all. >>>>>>>> >>>>>>>> IMPORTANT PART 1: You will need XCode 7.0 Beta 6 to run this build. >>>>>>>> IMPORTANT PART 2: Do run carthage again when you grab this - I've >>>>>>>> had to fork and port a whole pile of our dependencies today in order >>>>>>>> to get >>>>>>>> this building against XCode 7.0 Beta 6. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 24 August 2015 at 15:53, Richard Newman <rnew...@mozilla.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> I think you're heading in the right direction. I'll take a look >>>>>>>>> once I go through the painful steps to repro :D >>>>>>>>> >>>>>>>>> On Mon, Aug 24, 2015 at 7:14 AM, Emily Toop <et...@mozilla.com> >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Just realised I was sending these to a dead address. Here we go >>>>>>>>>> again. >>>>>>>>>> >>>>>>>>>> On 21 August 2015 at 16:16, Emily Toop <et...@mozilla.com> wrote: >>>>>>>>>> >>>>>>>>>>> I've been working this week on getting Firefox for iOS ported >>>>>>>>>>> over to using Swift 2.0 in preparation for work beginning on V1.0.x >>>>>>>>>>> and the >>>>>>>>>>> release of iOS9 in a few weeks. >>>>>>>>>>> >>>>>>>>>>> I am most of the way there, but I have now come up against a >>>>>>>>>>> compiler crash in the Storage module that I am utterly flummoxed by. >>>>>>>>>>> >>>>>>>>>>> Can anyone help me? >>>>>>>>>>> >>>>>>>>>>> You can find the code for the port at >>>>>>>>>>> https://github.com/mozilla/firefox-ios/pull/966 >>>>>>>>>>> >>>>>>>>>>> The compiler crash is >>>>>>>>>>> >>>>>>>>>>> Command failed due to signal: Abort trap: 6 >>>>>>>>>>> >>>>>>>>>>> It occurs when compiling the Storage module. >>>>>>>>>>> >>>>>>>>>>> The error output in the build is attached at >>>>>>>>>>> XCode7_Compiler_Crash.txt. >>>>>>>>>>> >>>>>>>>>>> Any help would be appreciated. I thought I had it narrowed down >>>>>>>>>>> to BrowserDB, but the further down the rabbit hole I went I >>>>>>>>>>> realised that >>>>>>>>>>> was a red herring. I suspect it is somewhere in SQLIteLogins >>>>>>>>>>> addLogin but >>>>>>>>>>> I'll be buggered if I can figure out where. >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> An update: I have managed to change the nature of the compiler >>>>>>>>>> crash to one that is a little more informative. See attached error >>>>>>>>>> log. >>>>>>>>>> >>>>>>>>>> In light of this I am going to go through all the classes/structs >>>>>>>>>> in the Storage module and ensure that all of our protocol >>>>>>>>>> implementations >>>>>>>>>> have complete signatures with the correct types. >>>>>>>>>> >>>>>>>>>> If that leads little insight I'm not sure where to go next. >>>>>>>>>> >>>>>>>>>> Have filed this compiler crash with apple: >>>>>>>>>> http://www.openradar.me/radar?id=4551431268859904 >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> _______________________________________________ >>>>>>>>>> mobile-firefox-dev mailing list >>>>>>>>>> mobile-firefox-dev@mozilla.org >>>>>>>>>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> mobile-firefox-dev mailing list >>>>>>>> mobile-firefox-dev@mozilla.org >>>>>>>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> mobile-firefox-dev mailing list >>>>>>> mobile-firefox-dev@mozilla.org >>>>>>> https://mail.mozilla.org/listinfo/mobile-firefox-dev >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >
_______________________________________________ mobile-firefox-dev mailing list mobile-firefox-dev@mozilla.org https://mail.mozilla.org/listinfo/mobile-firefox-dev