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

Reply via email to