column

I think it should work. A way to read the columns separately .btn-primary { color: #fff; background-color: #0275d8; border-color: #0275d8; } .btn { display: inline-block; font-weight: 400; line-height: 1.25; text-align: center; white-space: nowrap; vertical-align: middle; -webkit-user-select: none; -moz-user-select: none; -ms-user-select: none; user-select: none; border: 1px solid transparent; padding: .5rem 1rem; font-size: 1rem; border-radius: .25rem; -webkit-transition: all .2s ease-in-out; transition: all .2s ease-in-out; } label { display: inline-block; margin-bottom: .5rem; } //181b1d btn primary background-color: 37474F; .btn-primary.active, .btn-primary:active, .show>.btn-primary.dropdown-toggle { color: #fff; background-color: #025aa5; background-image: none; border-color: #01549b; } .btn-primary.focus, .btn-primary:focus { -webkit-box-shadow: ‪0 0 0 2‬px rgba(2, 117, 216, .5); box-shadow: ‪0 0 0 2‬px rgba(2, 117, 216, .5); } .btn-primary:hover { color: #fff; background-color: #025aa5; bo

I am having the same issue with the Column N.A. How can we solve this?

I have some potential progress, but due to the nature of this crash, I don't know if this is correct or not. After inspecting the sqlite-files that represents the backingdata, I discovered that a property backed by an integer was set to null after migration even the original value was 3. Upon inspection, I realized this was the very first property I ever migrated, so it was still annotated with @Attribute(orginalName: propertyName), even tho the migration which crashed for me was the 9th migration step overall for the app. Thus, with the Schema I was migrating from being: struct SchemaV7 { @Model class Item { @Attribute(originalName: propertyName) var newPropertyName: Int } } And then removing it in the destination Schema: struct SchemaV8 { @Model class Item { var newPropertyName: Int } } made me able to complete the migration without crashing. Wether this was the solution or not, I have no idea, but it could explain some of the crashes I've seen earlier... The property which was crashing the app have never b

Filtered columns behave like Swift ArraySlices. In particular they maintain the original indices, see ArraySlice, Slices Maintain Indices. You need to replace for i in 0 ... data.rows.count with for i in data.rows.indices. The other option is to convert the slice back to a regular DataFrame: let data = DataFrame(data0.filter { ... })

Hi Ziqiao, thank you for the suggestion. I tested using exclusionPaths instead and interestingly, the bug still occurs! I can send you the version of the project that uses exclusionPaths instead of different container sizes if you'd like to compile/run and see. For convenience, here is the changed code in question with exclusionPaths: setupLayout() changes to: func setupLayout() { var index = 0 for textViewData in PreviewTestData.textViewDataArray { self.ensureContainer(with: textViewData.frame.size, exclusionPath: textViewData.exclusionPath, at: index) index += 1 } } ensureContainer(...) changes to: @discardableResult private func ensureContainer(with size: CGSize, exclusionPath: NSBezierPath?, at index: Int) -> NSTextContainer { precondition(index >= 0 && index <= layoutManager.textContainers.count) if index == layoutManager.textContainers.count { let container = NSTextContainer(size: size) container.widthTracksTextView = false container.heightTracksTextView = false container.lineFragmentPa