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