Improve documentation for Realm pinning, style guide, and sharing realm with app extensions

I have been using Realm for over 5 years and established "best-practices" rules as the co-founder of social app startup's with millions of users. We use these tools to solve many issues that come with using Realm. There seems to be a substantial hole when it comes to Realm documentation for best practices. Here is the rough style guide our team has been using to avoid many realm gotchas including accessing invalidated objects, realm sizes ballooning to several gigabytes, and using Realm with app extensions.
These suggestions will be written authoritatively but there are many correct ways to use Realm, this is just what works for us.
The number one rule is this.

Never store references to Realm objects or queries except for NotificationToken (which must have invalidate called on within deinit.

We've developed many tools to assist with this. The first is ObjectReference
Instead of storing and passing Realm objects around between functions, we only pass ObjectReferences. These are thread safe and allow us to never worry about which thread we are accusing an Object on because they always pull a fresh object from the Realm when accessed. They're also way easier to work with than the clunky and confusing ThreadSafeReference(to: object) which is also a lot easier for an engineer to forget to do. These tools are possible because object(ofType:forPrimaryKey:) is extremely performant.
public class API {
    /// The shared API instance.
    public static let shared = API()
    private init() {}
	public static var realm: Realm? {
        return try? Realm()
    }
	public var realm: Realm? {
		return try? Realm()
	}

public extension String {
	/// Initializes an ObjectReference struct using the contents of the String as the id.
	/// - Returns: The Id struct.
	func ref<T:ModelProtocol>() -> ObjectReference<T> {
		return ObjectReference(id: self)
	}
}

public struct ObjectReference<T: ModelProtocol>: Equatable, CustomDebugStringConvertible {
	public let id: String

	public var object: T? {
		return API.realm?.object(ofType: T.self, forPrimaryKey: id)
	}
	public init(id: String) {
		self.id = id
	}
	public var debugDescription: String {
		return "\(T.type)/\(self.id)"
	}
	public static func == (lhs: Self, rhs: Self) -> Bool {
		return lhs.id == rhs.id && type(of: rhs) == type(of: lhs)
	}
}

We also developed IdsContainer to solve an issue we were having that we sometimes made requests to the server for several different objects and needed to keep track if they were deleted. This is essentially an RLMResults query for id IN array without actually running a query. We needed this because we found setting up notification tokens to be too slow and that they consumed too many resources when deep change checking. We enjoy using object references like public var friends = List<User>() and did not want to make our objects shallow so we created this instead.
public class IdsContainer<T: ModelProtocol> {
	public var ids: [String] = [] {
		didSet {
			self.didSet(self.ids)

		}
	}

	public var objects: [T] {
		return self.ids.compactMap { API.realm?.object(ofType: T.self, forPrimaryKey: $0) }
	}

	private let didSet: (([String]) -> Void)
	private let isIncluded: ((T) -> Bool)?

	private var notificationToken: NotificationToken? {
		didSet {
			oldValue?.invalidate()
		}
	}

	public init(isIncluded: ((T) -> Bool)? = nil, didSet: @escaping (([String]) -> Void)) {
		self.didSet = didSet
		self.isIncluded = isIncluded
		afterInit()
	}
	func afterInit() {
		self.notificationToken = API.realm?.observe { [weak self] notification, realm in
			guard let self = self else {
				return
			}
			let newIds = self.ids.compactMap { id -> String? in
				guard let object = API.realm?.object(ofType: T.self, forPrimaryKey: id) else { return nil }
				return self.isIncluded?(object) != false ? id : nil
			}
			if newIds.count != self.ids.count {
				self.ids = newIds
			}
		}
	}

	deinit {
		notificationToken?.invalidate()
	}
}

You use it like this:
	var displayedContentIdsContainer: IdsContainer<Content>?
	 displayedContentIdsContainer = IdsContainer { [weak self] in
			self?.tableView.reloadData() // Or use the `setIds` thing I show below
		}

If you also need the deleted moved inserted feature of notification tokens, you can build that into your application logic similar to this. I apologize for the extra code in here, I'm literally just copying from our project and not modifying anything. You will need to modify for your use case:
func set(contentIds newIds: [String]) {
		var adjustedIds = newIds
		if shouldShowAddPopPrompt, adjustedIds.first != "addPop" {
			adjustedIds.insert("addPop", at: 0)
		} else if !shouldShowAddPopPrompt, adjustedIds.first == "addPop" {
			adjustedIds.removeFirst()
		}
		if contentIds == adjustedIds { return }
		guard let oldIds = self.contentIds, oldIds.count > 0 else {
			guard adjustedIds != contentIds else { return }
			self.contentIds = adjustedIds
			self.collectionView.reloadData()
			return
		}
		var deletedRows = [Int]()
		var movedRows = [(fromRow: Int, toRow: Int)]()
		var insertedRows = [Int]()
		var newIndexLookup = [String:Int]()
		var oldIndexLookup = [String:Int]()

		for (index, newId) in adjustedIds.enumerated() {
			if newIndexLookup[newId] != nil {
				Log.fatal("Duplicate IDs Detected: \(newId)")
			}
			newIndexLookup[newId] = Int(index)
		}
		for (index, oldId) in oldIds.enumerated() {
			oldIndexLookup[oldId] = Int(index)
		}
		for (oldRow, id) in oldIds.enumerated() {
			if let newRow = newIndexLookup[id] {
				if newRow != oldRow {
					movedRows.append((fromRow: oldRow, toRow: newRow))
				}
			} else {
				deletedRows.append(oldRow)
			}
		}

		for (newRow, id) in adjustedIds.enumerated() {
			if oldIndexLookup[id] == nil {
				insertedRows.append(newRow)
			}
		}
		collectionView.performBatchUpdates({
			self.contentIds = adjustedIds
			collectionView.deleteItems(at: deletedRows.map { IndexPath(row: $0, section: FeedSection.content.rawValue) })
			movedRows.forEach { collectionView.moveItem(at: IndexPath(row: $0.fromRow, section:  FeedSection.content.rawValue), to: IndexPath(row: $0.toRow, section:  FeedSection.content.rawValue)) }
			collectionView.insertItems(at: insertedRows.map { IndexPath(row: $0, section:  FeedSection.content.rawValue) })
		}) { (completed) in
			Log.debug("Updated feed with result:", completed)
			self.collectionView.visibleCells.forEach { cell in
				(cell as? FeedCollectionViewCell)?.updateContent()
			}
		}

We established a rule that all Realm things are never retained so we also use getters a lot like this:
public var pendingContent: Results<Content>? {
		return API.realm?.objects(Content.self)
		.filter("uploaded_at = nil && local_media_paths.@count > 0")
	}

Before we invented ObjectReference, we used getters on objects as well like this:
var user: User? {
		return API.realm?.object(ofType: User.self, forPrimaryKey: userId)
	}
	var userId: String?

We also established a "write queue" very early on that is run in the background. ALL writes must be done on this one queue. We developed tools to assist this this:
public func writeSync(_ block: @escaping (Realm) -> Void) -> APIError? {
		self.backgroundQueue.sync {
			guard let realm = self.realm else {
				return APIError(message: "Failed to create realm")
			}
			do {
				try realm.write {
					block(realm)
				}
				return nil
			} catch (let error) {
				return APIError(realmError: error)
			}
		}
	}

	public func write(_ block: @escaping (Realm) -> Void , completion: @escaping (APIError?) -> Void) {
		let mainCompletion = { (error: APIError?) in
			DispatchQueue.main.async {
				completion(error)
			}
		}
		self.backgroundQueue.async {
			guard let realm = self.realm else {
				mainCompletion(APIError(message: "Failed to create realm"))
				return
			}
			do {
				try realm.write {
					block(realm)
				}
				mainCompletion(nil)
			} catch (let error) {
				mainCompletion(.init(realmError: error))
			}
		}
	}

Throughout the application we only write using this custom write function.
public static func deleteOutdated() {
		API.shared.write { realm in
			let searchHistories = realm
				.objects(SearchHistory.self)
				.sorted(byKeyPath: "updated_at", ascending: false)
			guard searchHistories.count > 20 else {
				return
			}
			searchHistories.suffix(from: 20).forEach {
				realm.delete($0)
			}
		} completion: { error in
			if let error = error {
				Log.error("Failed to delete search history", error)
			}
		}
	}

To avoid thread pinning, we have a few more rules. The first, all DispatchQueue's must be created using DispatchQueue.init and never DispatchQueue.global. This allows us to turn on autoreleaseFrequency: .workItem for all our queues and avoid realm pinning issues.
This is the queue we use for all writes to the Realm:
public let backgroundQueue = DispatchQueue(label: "myapp.api-background-queue", qos: .userInitiated, attributes: [], autoreleaseFrequency: .workItem, target: nil)

Another gotcha we are still working through is with App Extensions. We store our Realm in an app groups container so that it can be accessed by extensions. Here's that code:
public func applicationDidFinishLaunching(readOnly: Bool) {
		let directory = FileManager.default.containerURL(forSecurityApplicationGroupIdentifier: "group.myapp")
		let endpointURL = URL(string: Constants.endpoint)
        let config = Realm.Configuration(
			fileURL: directory?.appendingPathComponent("\(endpointURL?.host?.replacingOccurrences(of: "co", with: "xyz") ?? "api").realm"),
            syncConfiguration: nil,
			readOnly: readOnly,
            schemaVersion: UInt64(Date.timeIntervalSinceReferenceDate),
            migrationBlock: { migration, oldSchemaVersion in
                Log.debug("Migrating")
			},
			shouldCompactOnLaunch: { totalBytes, usedBytes in
				// totalBytes refers to the size of the file on disk in bytes (data + free space)
				// usedBytes refers to the number of bytes used by data in the file
				let tenMB = 10 * 1024 * 1024

				let isCompactNeeded = totalBytes > tenMB && (Double(usedBytes) / Double(totalBytes)) < 0.7
				Log.debug("Realm Size \(totalBytes)")
				Log.debug("Realm Used \(usedBytes)")
				if isCompactNeeded {
					Log.warn("Compacting Realm")
				}
				return isCompactNeeded
			},
			objectTypes: [User.self, SearchHistory.self])

        Realm.Configuration.defaultConfiguration = config
        do {
            let _ = try Realm()
        } catch let error {
            let apiError = APIError(realmError: error)
            apiError.log()
            let alert = apiError.toAlert { (_) in
                fatalError("Unable to recover from a bad launch.")
            }
            self.presentViewControllerOnNewWindow(alert)
        }
    }

Unfortunately, everything you think you knew about using the Realm on the Main thread falls apart when using App Extensions. The RunLoop for app extensions seems to be randomly paused. We have so far been able to resolve this by not pinning the Realm on the main thread. Luckily, our application was already almost entirely unpinned due to our style guide so this required only minor changes. We are still unsure how Realm writes are working in the extension since that is technically a different Thread. Our plan is to entirely separate the Realms for app extensions and the core app by doing this:

When extension launches, copy data from main Realm file to a separate extension Realm file.
Extension uses only it's own isolated Realm.
Periodically on the main app (and always on launch from notifications, etc), check the extension's Realm and copy over any data that is newer than the data in the current main Realm. This should allow us to use notification service extensions to pre-fetch data into our Realm.

We also found it helpful to conform all our Realm objects to a single protocol/class with a single id name. We use this for all our models:
public protocol ModelProtocol: Model {
	static var type: String { get }
}

public class Model: Object {
	required override init() {
		super.init()
	}
    @objc public dynamic var id: String?
    /// Casts the Model to ModelProtocol type.
    static var protocolConforming: ModelProtocol.Type {
        return self as! ModelProtocol.Type
    }
    /// Casts the Model to an instance of ModelProtocol type.
    var protocolConforming: ModelProtocol {
        return self as! ModelProtocol
    }
	public override static func primaryKey() -> String {
        return "id"
    }
// We have additional functions here available to all models to perform requests to the server.

We also have had issues with Realm pinning. We are usually able to isolate those issues using this tool (keywords: how can I find where my realm is pinning, realm file size balloons gigabytes). Note, this could require a lot of reworking of your application if you have been keep Realm objects around for more than one workItem. Expect lots of invalidated crashes when you turn this on:
public extension DispatchQueue {
	func fmlSync(execute: () -> Void) {

		self.sync {
			execute()
			if !Thread.current.isMainThread {
				API.realm?.invalidate()
			}
		}
	}
	func fml(execute: @escaping () -> Void) {

		self.async {
			execute()
			if !Thread.current.isMainThread {
				API.realm?.invalidate()
			}
		}
	}
	func fmlAfter(deadline: DispatchTime, block: @escaping () -> Void) {

		self.asyncAfter(deadline: deadline) {
			block()
			if !Thread.current.isMainThread {
				API.realm?.invalidate()
			}
		}
	}
}

Find and replace in your project async with fml and asyncAfter with fmlAfter. We called this feature fml because that's what you'll be sending in the Slack while you fix your pinning issues. We don't use this often since once pinning is removed, there is no need to invalidate the Realm. Also, this won't help you find memory leaked Realm objects but if you don't feel like tracking them down, it will make the issue appear to go away. As you get errors for invalidated objects, move that object to a getter, IdsContainer, or ObjectReference. I also recommend putting fatalError at the top of all extensions if the leak is still elusive. Simply crashing the extensions before they can pin a realm is a quick way to isolate if that's where one of the pinned realms is at.
Hopefully this is helpful to others experiencing issues with Realm. If you do all these things, you should never experience crashes from Realm while continuing to enjoy the multithreaded performance that Realm provides.
I'm sure I'm doing some things wrong and would love feedback! I would especially appreciate info from the Realm team regarding what happens when I use the same Realm in App Extensions and the app (multiple processes, one Realm).

Hey, happy to hear you've been using Realm so long! We always appreciate when the community reaches out to assist others. I have a few questions and queries for you:

Never store references to Realm objects or queries except for NotificationToken (which must have invalidate called on within deinit.

What made you come to this conclusion? I appreciate thread safety concerns (we're going to begin addressing them with the release of Swift 5.5), but beyond that, Realm objects and results are meant to be lightweight.

Instead of storing and passing Realm objects around between functions, we only pass ObjectReferences. These are thread safe and allow us to never worry about which thread we are accusing an Object on because they always pull a fresh object from the Realm when accessed. They're also way easier to work with than the clunky and confusing ThreadSafeReference(to: object) which is also a lot easier for an engineer to forget to do. These tools are possible because object(ofType:forPrimaryKey:) is extremely performant.

How is ThreadSafeReference clunky? If there is a way we can make the API clearer to users, we're all ears. TSR covers your use case and would be more efficient.

We also developed IdsContainer to solve an issue we were having that we sometimes made requests to the server for several different objects and needed to keep track if they were deleted. This is essentially an RLMResults query for id IN array without actually running a query. We needed this because we found setting up notification tokens to be too slow and that they consumed too many resources when deep change checking. We enjoy using object references like public var friends = List() and did not want to make our objects shallow so we created this instead.

Is this a side effect of having to synchronise between your local state and server state? My immediate thought is that this is one of the many reasons we created Realm Sync.
As far as deep change checking is concerned, that's a totally fair criticism, it can be slow. We're releasing KeyPath Filtering in the coming weeks, which will allow you to have finer grained notifications and avoid deep change checking if it doesn't apply to the use case.
For version pinning issues with Realm on different threads, couldn't you use autoreleasepool?
With the coming of async/await in Swift 5.5, structured concurrency with Swift and Realm will be one of our top priorities.
I've put together a small proof-of-concept here: https://github.com/realm/realm-cocoa/pull/7138. Do you think this would help you? Do you have any comments or concerns on it? It's our end goal to make it so that you (the user) do not have to think about Realm in the context of concurrency– it should "just work."

What made you come to this conclusion? I appreciate thread safety concerns (we're going to begin addressing them with the release of Swift 5.5), but beyond that, Realm objects and results are meant to be lightweight.
How is ThreadSafeReference clunky? If there is a way we can make the API clearer to users, we're all ears. TSR covers your use case and would be more efficient.

The biggest issue we had was with the way invalidated objects work. We found that our project was littered with checks to see if an object was invalidated. A ThreadSafeReference would crash when resolved if we didn't first check that it wasn't invalidated. Deleting an object from the Realm had been a never-ending source for crashes when objects are retained between threads. Simply calling async and using the object on the same (seemingly thread-safe) thread would cause crashes if we didn't first check if the object had been invalidated. By moving all objects to what are essentially Swift Optionals, we never have to check if an object or a Realm is invalidated. Also, it allows us to move all try-catch logic into one place where the specifics of errors are logged but other can be handled uniformly as simply an optional. From an application logic perspective, it has never mattered why an object wasn't available. All my application logic needs to know is that it's not, the optional is nil, and to update the UI accordingly.
Optionals are well understood by oncoming junior engineers. It's simply not practical to try-catch and handle every error in the thousands of places we use Realm. It's also too difficult for an engineer to make a mistake and unwrap a ThreadSafeReference without checking isInvalidated or access a Realm object on the same thread but different work item without checking isInvalidated. Those crashes might not show up in QA because they rely on rare edge cases that something is deleted in between two async operations and they will often ship to production. However, it's incredibly easy for an engineer to learn "never hold a reference to a Realm object" and it's incredibly easy to catch in code-review too. Plus, it's very performant. As far as we can tell from Time Profiler analysis, it is effectively as performant as ThreadSafeReferences or retaining objects is but without any of the headaches. Perhaps it's not technically as fast, but the difference is so insignificant as to not matter.
But also, I think the "why" is really obvious if I put it like this. Which one would you rather use?
Realm Method 1 (remember to use this if you'll be switching threads!):
let user = // User from some async operation
let threadSafeUserReference = ThreadSafeReference(to: user)
DispatchQueue.main.async { [weak self] in
  if !threadSafeUserReference.isInvalidated {
    try {
      let realm = try Realm()
      let threadSafeUser = realm.resolve(threadSafeUserReference)
      self?.nameLabel.text = threadSafeUser.name
    } catch (let err) {
      print(err)
      self?.nameLanbel.text = nil
    }
  }
}

Realm Method 2 (remember to only use this if you'll be on the same thread! You'll probably make a lot mistakes and get lots of crashes because you forgot an isInvalidated check):
let user = // User from some MAIN thread operation
someBackgroundOperation {
  DispatchQueue.main.async {
    // Did this pin the Realm? Who knows! Realm is a mystery black box that just crashes a lot.
    self?.nameLabel.text = user.isInvalidated ? nil : user.name
  }
}

The "it just works, it doesn't matter the situation, and your junior engineers don't make mistakes" @IsaiahJTurner  Method:
  let userRef = // ObjectReference<User> from some async operation
  DispatchQueue.main.async { [weak self] in
   self.nameLabel.text = userRef.object?.name
  }
}

Is this a side effect of having to synchronise between your local state and server state? My immediate thought is that this is one of the many reasons we created Realm Sync.

We need to display the equivalent of “tweets” for any random user when tapping on their profile. There could be tens of thousands of tweets so we use cursors for server side pagination. However, someone may delete one of their tweets on one page of the app and that tweet should disappear from all other pages of the app as well without needing to perform network calls again on every page. Keep in mind, this is not a Realm Sync thing. We don't care if other users still see the tweet until they refresh. The user just needs to feel confident that it was deleted. So, we delete the object from the realm but that doesn’t remove it from all other places in the app. IdsContainers will automatically call its didSet function when an Id in the container is removed from the Realm which will remove the tweet from all places in the app. Realm Sync is not an option for us. It looks like it would've been a nice alternative way back when we used firebase but at this point, we're on DynamoDB using GSI overloading behind a DAX cluster and managing Global Tables to shave off milliseconds from requests. We're long past the managed solutions phase of the company.
KeyPath Filtering should help a lot with that. I’m looking forward to that. Ultimately though, we will still use IdsContainer because otherwise we’d be rewriting the same logic over and over in NotificationTokens. We’d have dozens of NotificationTokens that just compactMap the Object IDs in the results and update the UI accordingly.

The last thing we are actually struggling with, the autoreleasepools stuff. Everything had been fine until we started using Notification Content Extensions, Notification Service Extensions, and Share Extensions. We are trying to use the same Realm file with these extensions via an App Group but they seem to be pinning the Realm.
We use autoreleaseFrequency workItem (DispatchQueue(label: "poparazzi.content-background-queue", qos: .utility, attributes: [], autoreleaseFrequency: .workItem, target: nil)) on all of our threads so every background block is automatically wrapped in an autoreleasepool. This seems to be working just fine in our main application but users who get notifications always see their Realm balloon until the app starts crashing.
Do NotificationTokens pin the Realm? That was the only thing I could think of. They are created on a main thread but it's the main thread of a different process. Potentially when iOS is suspends the application or extension, the one which is still suspended pins the Realm on its own main thread. The Realm docs don't indicate anything like this and everything suggests that extensions should "just work."

Looking up at my previous answer, even more reasons not to use TSRs. I made a mistake myself just writing my example! It should have been like this:
let user = // User from some async operation
let threadSafeUserReference = ThreadSafeReference(to: user)
DispatchQueue.main.async { [weak self] in
  if threadSafeUserReference.isInvalidated {
    self?.nameLanbel.text = nil
  } else {
    try {
      let realm = try Realm()
      let threadSafeUser = realm.resolve(threadSafeUserReference)
      self?.nameLabel.text = threadSafeUser.name
    } catch (let err) {
      print(err)
      self?.nameLanbel.text = nil
    }
  }
}

Otherwise, stale data could remain in the UI when a Realm object was invalidated between async calls.

@IsaiahJTurner did you resolve the extension pinning issue?


⚠ Samsung has degraded performance

In 9c1931a, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 3295 ms

Resolved: Samsung performance has improved in 794c8d2.


[Bug]: on-run-end hook fails due to exceeding maximum standard SQL query length in BigQuery

Overview
For dbt_artifact versions 2.4.0, 2.4.1, and 2.4.2 (and dbt-core 1.4.5) the on-run-end hook fails with the error:
15:33:29  on-run-end failed, error:
15:33:29   The query is too large. The maximum standard SQL query length is 1024.00K characters, including comments and white space characters.

How to reproduce
Specify dbt_artifacts version 2.4.0, 2.4.1, or 2.4.2 in packages.yml and run the command dbt clean && dbt deps && dbt run --full-refresh --select dbt_artifacts
Expected behaviour
The command completes successfully. Note that dbt_artifacts version 2.3.0 produces the expected behavior.
Screenshots
$ dbt clean && dbt deps && dbt run --full-refresh --select dbt_artifacts
15:32:23  Running with dbt=1.4.5
15:32:23  Checking target/*
15:32:23  Cleaned target/*
15:32:23  Checking dbt_packages/*
15:32:23  Cleaned dbt_packages/*
15:32:23  Finished cleaning all paths.
15:32:26  Running with dbt=1.4.5
15:32:26  Installing dbt-labs/dbt_utils
15:32:26    Installed from version 1.1.1
15:32:26    Up to date!
15:32:26  Installing calogica/dbt_expectations
15:32:27    Installed from version 0.8.5
15:32:27    Up to date!
15:32:27  Installing dbt-labs/codegen
15:32:27    Installed from version 0.10.0
15:32:27    Up to date!
15:32:27  Installing data-mie/dbt_profiler
15:32:27    Installed from version 0.7.0
15:32:27    Up to date!
15:32:27  Installing dbt-labs/dbt_project_evaluator
15:32:27    Installed from version 0.6.2
15:32:27    Up to date!
15:32:27  Installing dbt-labs/metrics
15:32:27    Installed from version 1.4.1
15:32:27    Up to date!
15:32:27  Installing brooklyn-data/dbt_artifacts
15:32:27    Installed from version 2.4.2
15:32:27    Up to date!
15:32:27  Installing elementary-data/elementary
15:32:27    Installed from version 0.8.4
15:32:27    Up to date!
15:32:27  Installing dbt-labs/audit_helper
15:32:27    Installed from version 0.9.0
15:32:27    Up to date!
15:32:27  Installing calogica/dbt_date
15:32:27    Installed from version 0.7.2
15:32:27    Up to date!
15:32:27
15:32:31  Running with dbt=1.4.5
15:32:31  Unable to do partial parsing because saved manifest not found. Starting full parse.
15:32:52  Found 320 models, 163 tests, 2 snapshots, 0 analyses, 1456 macros, 1 operation, 17 seed files, 113 sources, 1 exposure, 1 metric
15:32:52
15:32:54  Concurrency: 4 threads (target='dev')
15:32:54
15:32:54  1 of 34 START sql incremental model dbt_test.exposures .................. [RUN]
15:32:54  2 of 34 START sql incremental model dbt_test.invocations ................ [RUN]
15:32:54  3 of 34 START sql incremental model dbt_test.model_executions ........... [RUN]
15:32:54  4 of 34 START sql incremental model dbt_test.models ..................... [RUN]
15:32:57  2 of 34 OK created sql incremental model dbt_test.invocations ........... [CREATE TABLE (0.0 rows, 0 processed) in 2.87s]
15:32:57  5 of 34 START sql incremental model dbt_test.seed_executions ............ [RUN]
15:32:57  4 of 34 OK created sql incremental model dbt_test.models ................ [CREATE TABLE (0.0 rows, 0 processed) in 2.88s]
15:32:57  6 of 34 START sql incremental model dbt_test.seeds ...................... [RUN]
15:32:57  1 of 34 OK created sql incremental model dbt_test.exposures ............. [CREATE TABLE (0.0 rows, 0 processed) in 2.95s]
15:32:57  7 of 34 START sql incremental model dbt_test.snapshot_executions ........ [RUN]
15:32:57  3 of 34 OK created sql incremental model dbt_test.model_executions ...... [CREATE TABLE (0.0 rows, 0 processed) in 3.17s]
15:32:57  8 of 34 START sql incremental model dbt_test.snapshots .................. [RUN]
15:32:59  5 of 34 OK created sql incremental model dbt_test.seed_executions ....... [CREATE TABLE (0.0 rows, 0 processed) in 2.37s]
15:32:59  9 of 34 START sql incremental model dbt_test.sources .................... [RUN]
15:33:00  6 of 34 OK created sql incremental model dbt_test.seeds ................. [CREATE TABLE (0.0 rows, 0 processed) in 2.56s]
15:33:00  10 of 34 START sql incremental model dbt_test.test_executions ........... [RUN]
15:33:00  7 of 34 OK created sql incremental model dbt_test.snapshot_executions ... [CREATE TABLE (0.0 rows, 0 processed) in 2.82s]
15:33:00  11 of 34 START sql incremental model dbt_test.tests ..................... [RUN]
15:33:00  8 of 34 OK created sql incremental model dbt_test.snapshots ............. [CREATE TABLE (0.0 rows, 0 processed) in 2.69s]
15:33:00  12 of 34 START sql view model dbt_test.stg_dbt__invocations ............. [RUN]
15:33:01  12 of 34 OK created sql view model dbt_test.stg_dbt__invocations ........ [CREATE VIEW (0 processed) in 0.65s]
15:33:01  13 of 34 START sql view model dbt_test.stg_dbt__models .................. [RUN]
15:33:02  13 of 34 OK created sql view model dbt_test.stg_dbt__models ............. [CREATE VIEW (0 processed) in 0.92s]
15:33:02  14 of 34 START sql view model dbt_test.stg_dbt__exposures ............... [RUN]
15:33:02  10 of 34 OK created sql incremental model dbt_test.test_executions ...... [CREATE TABLE (0.0 rows, 0 processed) in 2.31s]
15:33:02  15 of 34 START sql view model dbt_test.stg_dbt__model_executions ........ [RUN]
15:33:02  14 of 34 OK created sql view model dbt_test.stg_dbt__exposures .......... [CREATE VIEW (0 processed) in 0.58s]
15:33:02  16 of 34 START sql view model dbt_test.stg_dbt__seed_executions ......... [RUN]
15:33:02  9 of 34 OK created sql incremental model dbt_test.sources ............... [CREATE TABLE (0.0 rows, 0 processed) in 2.80s]
15:33:02  17 of 34 START sql view model dbt_test.stg_dbt__seeds ................... [RUN]
15:33:02  11 of 34 OK created sql incremental model dbt_test.tests ................ [CREATE TABLE (0.0 rows, 0 processed) in 2.40s]
15:33:02  18 of 34 START sql view model dbt_test.stg_dbt__snapshot_executions ..... [RUN]
15:33:03  15 of 34 OK created sql view model dbt_test.stg_dbt__model_executions ... [CREATE VIEW (0 processed) in 0.81s]
15:33:03  19 of 34 START sql view model dbt_test.stg_dbt__snapshots ............... [RUN]
15:33:03  17 of 34 OK created sql view model dbt_test.stg_dbt__seeds .............. [CREATE VIEW (0 processed) in 0.80s]
15:33:03  20 of 34 START sql view model dbt_test.fct_dbt__invocations ............. [RUN]
15:33:03  16 of 34 OK created sql view model dbt_test.stg_dbt__seed_executions .... [CREATE VIEW (0 processed) in 0.85s]
15:33:03  21 of 34 START sql view model dbt_test.dim_dbt__models .................. [RUN]
15:33:03  18 of 34 OK created sql view model dbt_test.stg_dbt__snapshot_executions  [CREATE VIEW (0 processed) in 0.75s]
15:33:03  22 of 34 START sql view model dbt_test.stg_dbt__test_executions ......... [RUN]
15:33:04  19 of 34 OK created sql view model dbt_test.stg_dbt__snapshots .......... [CREATE VIEW (0 processed) in 0.79s]
15:33:04  23 of 34 START sql view model dbt_test.dim_dbt__exposures ............... [RUN]
15:33:04  22 of 34 OK created sql view model dbt_test.stg_dbt__test_executions .... [CREATE VIEW (0 processed) in 0.56s]
15:33:04  21 of 34 OK created sql view model dbt_test.dim_dbt__models ............. [CREATE VIEW (0 processed) in 0.60s]
15:33:04  24 of 34 START sql view model dbt_test.stg_dbt__sources ................. [RUN]
15:33:04  25 of 34 START sql view model dbt_test.stg_dbt__tests ................... [RUN]
15:33:04  20 of 34 OK created sql view model dbt_test.fct_dbt__invocations ........ [CREATE VIEW (0 processed) in 0.70s]
15:33:04  26 of 34 START sql view model dbt_test.dim_dbt__current_models .......... [RUN]
15:33:04  23 of 34 OK created sql view model dbt_test.dim_dbt__exposures .......... [CREATE VIEW (0 processed) in 0.63s]
15:33:04  27 of 34 START sql view model dbt_test.fct_dbt__model_executions ........ [RUN]
15:33:04  25 of 34 OK created sql view model dbt_test.stg_dbt__tests .............. [CREATE VIEW (0 processed) in 0.60s]
15:33:04  28 of 34 START sql view model dbt_test.dim_dbt__seeds ................... [RUN]
15:33:04  24 of 34 OK created sql view model dbt_test.stg_dbt__sources ............ [CREATE VIEW (0 processed) in 0.84s]
15:33:04  29 of 34 START sql view model dbt_test.fct_dbt__seed_executions ......... [RUN]
15:33:05  26 of 34 OK created sql view model dbt_test.dim_dbt__current_models ..... [CREATE VIEW (0 processed) in 0.90s]
15:33:05  30 of 34 START sql view model dbt_test.fct_dbt__snapshot_executions ..... [RUN]
15:33:05  27 of 34 OK created sql view model dbt_test.fct_dbt__model_executions ... [CREATE VIEW (0 processed) in 0.81s]
15:33:05  31 of 34 START sql view model dbt_test.dim_dbt__snapshots ............... [RUN]
15:33:05  28 of 34 OK created sql view model dbt_test.dim_dbt__seeds .............. [CREATE VIEW (0 processed) in 0.80s]
15:33:05  32 of 34 START sql view model dbt_test.fct_dbt__test_executions ......... [RUN]
15:33:05  30 of 34 OK created sql view model dbt_test.fct_dbt__snapshot_executions  [CREATE VIEW (0 processed) in 0.52s]
15:33:05  33 of 34 START sql view model dbt_test.dim_dbt__tests ................... [RUN]
15:33:05  29 of 34 OK created sql view model dbt_test.fct_dbt__seed_executions .... [CREATE VIEW (0 processed) in 0.80s]
15:33:05  34 of 34 START sql view model dbt_test.dim_dbt__sources ................. [RUN]
15:33:06  31 of 34 OK created sql view model dbt_test.dim_dbt__snapshots .......... [CREATE VIEW (0 processed) in 0.82s]
15:33:06  34 of 34 OK created sql view model dbt_test.dim_dbt__sources ............ [CREATE VIEW (0 processed) in 0.63s]
15:33:06  33 of 34 OK created sql view model dbt_test.dim_dbt__tests .............. [CREATE VIEW (0 processed) in 0.86s]
15:33:06  32 of 34 OK created sql view model dbt_test.fct_dbt__test_executions .... [CREATE VIEW (0 processed) in 0.95s]
15:33:06
15:33:06  Running 1 on-run-end hook
15:33:06  Uploading model executions
15:33:08  Uploading seed executions
15:33:08  Uploading snapshot executions
15:33:08  Uploading test executions
15:33:08  Uploading exposures
15:33:10  Uploading tests
15:33:13  Uploading seeds
15:33:15  Uploading models
15:33:29  Database error while running on-run-end
15:33:29
15:33:29  Finished running 11 incremental models, 23 view models in 0 hours 0 minutes and 36.26 seconds (36.26s).
15:33:29
15:33:29  Completed with 1 error and 0 warnings:
15:33:29
15:33:29  on-run-end failed, error:
15:33:29   The query is too large. The maximum standard SQL query length is 1024.00K characters, including comments and white space characters.
15:33:29
15:33:29  Done. PASS=34 WARN=0 ERROR=1 SKIP=0 TOTAL=35

Environment
Results of running dbt --version:
$ dbt --version
Core:
  - installed: 1.4.5
  - latest:    1.5.3 - Update available!

  Your version of dbt-core is out of date!
  You can find instructions for upgrading here:
  https://docs.getdbt.com/docs/installation

Plugins:
  - bigquery: 1.4.3 - Update available!

  At least one plugin is out of date or incompatible with dbt-core.
  You can find instructions for upgrading here:
  https://docs.getdbt.com/docs/installation

Please paste the contents of your packages.yml file here:
packages:
  - package: dbt-labs/dbt_utils
    version: [">=1.1.0", "<1.2.0"]
  - package: calogica/dbt_expectations
    version: [">=0.8.0", "<0.9.0"]
  - package: dbt-labs/codegen
    version: [">=0.10.0", "<0.11.0"]
  - package: data-mie/dbt_profiler
    version: [">=0.7.0", "<0.8.0"]
  - package: dbt-labs/dbt_project_evaluator
    version: [">=0.6.0", "<0.7.0"]
  - package: dbt-labs/metrics
    version: [">=1.4.0", "<1.5.0"]
  - package: brooklyn-data/dbt_artifacts
    version: "2.4.0"
  - package: elementary-data/elementary
    version: [">=0.8.0", "<0.9.0"]
  - package: dbt-labs/audit_helper
    version: [">=0.9.0", "<1.0.0"]

Hello. I've just put out a release which will hopefully help here. In a previous release, we added an additional all_results column which contained a JSON object of all results for people to be able to do their own analysis on. However, this increased the query size dramatically, which is why these issues started arising.
In the latest release, I've added a variable that will stop this behaviour to reduce the query size. Please can you try adding the following as a variable in your dbt_project.yml file and see if that resolves it?
dbt_artifacts_exclude_all_results: true

I was too fast. It works now.
14:18:09  Running with dbt=1.6.3
14:18:09  Installing brooklyn-data/dbt_artifacts
14:18:09  Installed from version 2.6.0
14:18:09  Up to date!

No 'query to large' errors anymore here (which we had in 2.4 and 2.5)


Fix object fields links

Fix object fields links
Checklist

[x] By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license and subject to the Developers Certificate of Origin.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

Closing this PR. Will raise another one manually.


Use chardet rather than charset_normalizer

Otherwise multipart upload gets dwave.cloud.exceptions.ProblemUploadError: Multipart upload of problem_id='...' failed for part_no=1 with InvalidAPIResponseError('JSON response expected').

Codecov Report

Merging #471 (8d86add) into master (d06aaaa) will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #471   +/-   ##
=======================================
  Coverage   83.46%   83.46%
=======================================
  Files          16       16
  Lines        2637     2637
=======================================
  Hits         2201     2201
  Misses        436      436

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update d06aaaa...8d86add. Read the comment docs.

See also https://github.com/psf/requests/issues/5871 (just posted a few hours ago).
I imagine there is a more elegant fix, but specifying the encoder explicitly.


Flexible payout for validator and all nominators

IN PROGRESS: THIS PR NEEDS TO BE POLISHED WITH ADDITIONAL TESTS.
This is a PR which introduces an alternative payout mechanism somewhere in the middle of automatic payouts and lazy payouts.
Main problems to be solved:

With automatic payouts, we were triggering payouts for all users at a single block. This was a ton of computation, and causing the block production to stall. This was not economically viable for the long term as more and more validators and nominators joined the system.
With lazy payouts every validator and nominator needed to request payouts for all of their rewards. This punished small nominators who may pay more in underlying fees than they would be rewarded. Furthermore, it required all users actively claim their rewards every 84 eras.

Solution:
Create a payout mechanism that pays out to a validator and all nominators for that validator in a single transaction.
Intended Behavior:
Validators are the ones most incentivized to claim rewards as they are the ones most likely to receive the largest cut of the pie. They are also most likely to stay up to date with the network and regularly interact with it through transactions, voting, etc...
Validators want nominators to select them so that they stay in the validator pool.
As a result, we can put the ownership of making payouts to the validators, and allow nominators to get the much preferred "automatic payout"-like system
Changes:

Remove payout_nominator
Combine do_payout_validator and do_payout_nominator
Replace last_reward single value storage tracker with claimed_rewards vector

claimed_rewards is a vector which keeps track of all the eras a validator has made a claim between the current era and current era - history_depth. This allows for out of order claiming.

Introduce max_payout validator preference, allowing them to select how many users to pay out to in an era.
Make payout_validator callable by anyone where they specify the validator to pay out.
Removed ErasStakersClipped which redundantly kept the same data around. (Although maybe we should keep it as it would reduce storage read at the time of claiming...)

Features:

The main feature of this PR is that nominators need to do nothing in order to get paid by the staking system. For nominators, it feel as if we had automatic payouts.
The burden is then placed on validators, who should regularly claim rewards, and will automatically payout all their validators.
Paying out more nominators will inherently increase the fee of making a payout. So a validator can now signal their intention of the max number of nominators they want to payout. This allows them to control the max fee they will pay for their own payout, and remove any attack vector where micro-nominators would make it too hard for the validator to claim their rewards. This is configurable per validator unlike lazy payouts which is global.
Nominators can now use this max_payout preference to help in their decision making when selecting nominators. If a validator selects max_payout = 1, they are guaranteed to pay a very low fee when claiming rewards, but not many nominators would be incentivized to select them. So a middle ground is good, and the default is currently 64, just like in lazy payouts.
Validators are not strictly required to make a payout transaction. The extrinsic has been updated so that it can be called by anyone. This allows nominators who may have significant rewards to claim those rewards by making a payout on behalf of the validator. Additionally, a validator need not pull out their controller keys to make regular payouts, they can just simply use any burner account to make a transaction to payout their validator account and all their nominators. To support this, we need to support out of order claiming, which I have added by tracking which eras the user has claimed in a truncated vector.

TODO:

[ ] Get feedback that this is a reasonable direction.

[ ] Polish code to make sure it is well optimized for storage/computation.

[ ] Benchmark the new extrinsic to compare performance in expected real world scenarios as compared to lazy payouts.

[ ] Write comprehensive tests verifying features and functionality.

cc @jacogr @thiolliere @gavofyork

additional note: if the fees to claim reward for a validator and its n first nominators is important, maybe nobody wants to claim and one has to, at the end, pay the fee "for other". But this can be solved by paying the fee of claiming reward from inside the reward. A staker would claim the reward, it will first take from the total_reward for the validator and n nominator a small part corresponding to the fee.
Thus the staker at the end pay zero fee from claiming for other.

I have not updated docs, but the code + tests should tell anyone with an opinion if they like the design or not. Feel free to review, and if it is positive, then I will complete the work needed here.

Superseded by #5406


Push rules spec still has references to per-device scopes

Which don't exist
https://matrix.org/docs/spec/client_server/r0.6.1#get-matrix-client-r0-pushrules-scope-kind-ruleid-actions
https://matrix.org/docs/spec/client_server/r0.6.1#get-matrix-client-r0-pushrules-scope-kind-ruleid-enabled
or device/<profile_tag> to specify global rules or device rules for the given profile_tag.

I think this is https://github.com/matrix-org/matrix-doc/issues/2616?


KAFKA-17874: Fix the KRaft metric names in the documentation

As title
Committer Checklist (excluded from commit message)

[ ] Verify design and implementation
[ ] Verify test coverage and CI build status
[ ] Verify documentation (including upgrade notes)

Thanks for the PR. Can you also fix the incorrect names in https://kafka.apache.org/documentation/#kraft_broker_monitoring? Their Mbean name is just kafka.server:type=broker-metadata-metrics.

@mimaison   Sure, I have fixed it, PTAL


HSEARCH-2591 Upgrade to Apache Lucene 5.5.4

Very complex patch ;)
But important: it fixes the Java 9 memory un-mapping problem.

Jenkins, test this please

Jenkins, retest this please

Rebased and merged. And backported to 5.6. Thanks!


tests contains inadvertent config properties

@Download This error seems to be a problem in the test case. The config of ulog contains {log: 'pass'} so the log level become NaN which is true :grin:
The question now: Why are the configs log and test either 'ok' or 'pass'?
I added some console outputs in mods/config/index.js:
update: function(ulog) {
  ...
  var changed = update(ulog.config, newCfg)
  console.log("changed: ", changed);
  ...
},

...

after: function (logger) {
  console.log("after [logger.level]: ", logger.level);
  config.update(this);
  console.log("after [logger.level]: ", logger.level);
}

Console output:
after [logger.level]:  3
changed:  [
  { name: 'test', old: 'ok', new: 'pass' },
  { name: 'log', new: 'pass' },
  { name: 'log_output', new: 'console;test=drain' }
]
after [logger.level]:  NaN

Originally posted by @Messj1 in https://github.com/Download/ulog/issues/58#issuecomment-813024640

My idea was to test mods completely independent from ulog itself. But I have not been very consistent about this.


Add an e2e test to verify that pods are deleted on nodes

The test verifies that kubelet deletes the pods/containers within a
reasonable time. It queries the kubelet /runningpods endpoint to retrieve a
list of running pods directly. The outline of the test is:

Create an RC
Wait until all pods are running (based on the pod status)
status)
Verify pods are running by querying the /runningpods
Delete the RC
Check all pods are deleted by querying /runningpods

Risk: low. This PR adds an endpoint in the kubelet server and use it for the new e2e test. The endpoint is not used by any other production code, so it should be pretty safe.
Value: Currently we don't have any test verifying that kubelet actually deletes the pods/containers on the node. This new test would be able to verify that, and also signal if deletion took an abnormally long time.

/cc @dchen1107

The new push moves /runningpods handler registration to InstallDebuggingHandlers since it's only used for testing.

OK, seems like we know what to do to finish this one off.  Re-assigning back to @yujuhong to make the final tweaks.  Please assign back to me when it's ready for final review.

e2e failure looks like a flake.  Trying again.
@k8s-bot test this please

@k8s-bot test this please

ping @yujuhong .  Any progress?  Seems we're very close to merging this one.

@quinton-hoole, sorry for the delay, I was OOO on Friday. I am working on the PR and will upload soon.

Rebased and addressed the comments (shorten the timeout, parallelizing the pod checking, switching to use pod name prefix to filter pods). PTAL!
Note that the test assumes that the pods created by RC will be spread somewhat evenly among the nodes, but this does not happen because of #10242 (for pods in the non-default namespace). As the results, all pods may be scheduled onto one node until the issue is resolved. The test will still pass, but only one node is actually tested.

@k8s-bot ok to test.

LGTM from me, but I'd really like one more pair of eyes on the kubelet code before we merge this.  Assigning to @dchen1107 for LGTM, ok-to-merge, although @lavalamp could also do this if he has time.

I do have concern to introduce arbitrary endpoint to kubelet, but since you only register this for debugging handler, which should be ok.
LGTM. I only reviewed kubelet changes, and totally trust @quinton-hoole 's review on testing side. :-)

go v1.3 doesn't like the for range { syntax. Fixed that and pushed again. The rest of the code remains unchanged.

go v1.3 doesn't like the for range { syntax. Fixed that and pushed again. The rest of the code remains unchanged.

ok...I pushed again because gofmt (v1.4) didn't like that version. Hopefully this one would please both.


LANG-1652 - Check whether the given class has a public constructor

Determine whether the given class has a public constructor with the given signature, checking accessibility.

Coverage increased (+0.0003%) to 94.937% when pulling 60d73e2a4aabd24305e6b34ad5bd01af2da410d1 on arturobernalg:feature/LANG-1652 into 69c9593cc1da760bb4dbcf32f4ae755c54376b77 on apache:master.

@arturobernalg
I am curious: Can this be used within Commons Lang itself?

Hi @garydgregory We have a complete class dedicated to manipulate and access to the method of a class through reflections, so, IMO why not.

Not, because (1) It's not useable within Commons Lang itself, because current callers of getAccessibleConstructor(*) test and use the result of the call. So using this new API internally would cause getAccessibleConstructor() to be called more than once instead of once. And (2) because "why not" is not a use-case, so YAGNI.


epic-hp: controlplane

This PR implements the EPIC control plane changes as described in [1]. It improves the structure of the previous PR [2] according to the suggestion from [3].

Add an EPICDetachedExtension to the beacon. This extension does not get signed and can therefore be detached.
Add a DigestExtension to the PathSegmentExtensions, which holds the hash of EPICDetachedExtension. This hash is therefore signed.
Overhead: no new MAC needs to be calculated, only one additional hash per AS.

[1] https://scion.docs.anapaya.net/en/latest/EPIC.html#control-plane
[2] https://github.com/scionproto/scion/pull/3944
[3] https://github.com/scionproto/scion/commit/3a5ea8e8bce43ccb4407ce2e2056475c9320820c

This change is

Hi @mawyss fyi, this PR has not been forgotten but we are lacking the time and the resources to have a look.

Hi @mawyss fyi, this PR has not been forgotten but we are lacking the time and the resources to have a look.

I cannot personally estimate but probably will be beginning of February.

I cannot personally estimate but probably will be beginning of February.

/rebase


Do not check e2e-sse for ci

/kind improvement

/lgtm
chatted with cydrain, after this PR:

if all other checks passed, ci will pass and pr will be auto-merged even if e2e-sse is still running
after the pr is merged, e2e-sse job will likely continue running
e2e-sse will later be moved to nightly, so it'll not run for each individual pr, but run periodically on itself.


Socket io 1

ee13d7c Removes socket.io (client) as dependency for bundling erizo.js
Motivation: many client libraries using distributed erizo.js client code won't need extra bundled socket.io, and it's true they can tools/compile.* it again without included socket.io it would be nice to have it aside. Erizo api consumers will be able to simply take distributed erizo.js file and use own socket.io already present in their environment (amd,requirejs cases)
cc12509 Updates to new socket.io server and client (1.3.6)
Because we can't easily use new socket.io-client with GCC, ee13d7c makes here even more sense.

I wonder is there any reason this PR has not been merged?! I have requested for the migration here #476 and enumerated advantages of Socket.io 1.

Just speculating, but it likely hasn't been merged because it would be a breaking change for many people.  0.9 is not compatible with 1.0+ servers, so updating for many people is a lot more complicated than a version bump server-side.

You're right @jnoring, the two versions are not compatible but using the old version in the core also prevents people from using the newer version in their apps and benefiting from a lot of features and enhancements due to version conflicts (on the client side at least).
I don't see any milestone or versioning plan for Licode and this means we have to stick to an outdated, poor and buggy module which is for five years ago!

@mkhahani having and old version do not prevent you from using a newer one, the trick is how you configure socketIO, if you serve any version of the lib from /, all apps trying to fetch the lib from there will fetch that version, perhaps Licode is wrong about hardcoding the way it serves socketIO but if you want to install a newer version to be used by other apps you could use this parameter for example:
var io = require('socket.io')(http, {path: "/ackuaria/socket.io/"});

@zevarito yeah, than everyone who want to use an old version should do this that way.
What you should not do, is using old dependencies because someone have to update his code as well.
My opinion: @mkhahani is right, this project should get a versioning plan.

Thanks for the responses.
@zevarito the problem is in the client side. Assume a single page application which is talking with ErizoClient via the old version of the Socket.io module and at the same time needs to load the newer version of the Socket.io client to connect to the app server which is running on version 1+.

@mkhahani There is no problem with that, you can easily fetch two versions of SocketIO from client side.

At server side you require SocketIO serving it from a custom path:

var io = require('socket.io')(http, {path: "/path/socket.io/"});

Then at client side you load the library like this:

Place the code bellow right before Licode's socketIO is fetched.
<script src="/path/socket.io.js"></script>
    <script type="text/javascript">
       // Keep `io` before Licode SocketIO gets loaded and override it.
       ioSafe = io;
    </script>
</script>

The result should be...
ioSafe -> version 1.x
io -> Licode's socketIO version (0.96)

Then to fetch 1.x version from the server you need to do this in your client side code:

var socket = ioSafe('/', {path: '/path/socket.io'});

I agree that could be nice to upgrade to SocketIO and that will be cool if Licode starts to versioning releases.

A proper versioning plan is a must, but I suppose noone has time for it now.
Some people probably can't allow to include 2 socket.io versions because of the overhead or simply extra KB.
I don't really see the problem, if licode needs to support older, deprecated socket.io 0.9, then we can:

support on server both versions, controlled by USE_OLD_SOCKET_IO = true (let core maintainers decide if this should be on/off by default)
front end clients then can use any (old or new) version, they will just need to adjust USE_OLD_SOCKET_IO on the server.

This way everyone is happy, more importantly other users are happier because they are not forced to use deprecated socket.io.
Then deprecation or versioning plan is made and old version can be marked as soon to be deprecated.

@zevarito Are you sure the trick works just by overriding the io variable? Any other global variables or side effects?
@patrickm We don't have to do much for versioning. We can simply start a new version (e.g. v2) just by creating a new branch and targeting some major changes. Then we have a working copy that is supposed to include new features and enhancements. People can also use it with care due to instability. We would have to commit minor changes and bug fixes to both branches for a while but our main focus is now on the new version. This way people have time to migrate to the new version and we can deprecate the old version after the new one got stable.
Right now I can see some Issues which are held because they need some surgery to be done or they create incompatibility issues. By creating the new branch we can assign them to a new milestone and work on them without compatibility or stability concerns. Here are some of them and I'm sure there would be more:

Migrate to Socket.io 1 #476
Replace browsers stack by Adapter.js  #374
Replace OpenSSL by BoringSSL #233
Replace libav by ffmpeg #232
Add VP9 support #415
Add Data Channel support #309
Add Opus support by default #420

@mkhahani it works for me.

@zevarito Thank you. It works well. I just didn't get the point with server path. The two servers are running on different ports so using path` does not make sense, right?

@mkhahani doesn't look like SocketIO client is able to define the port as-well, but in that case you can proxy it from your webserver.

@zevarito The port is part of the URL and I have no problem with it:
socket = io('http://www.mydomain.com:3000/');
socketNew = ioNew('http://www.mydomain.com:3001/');

Although I'm curios to know which one is preferred, running two SocketIO server instances (despite of the their versions) or a single instance serving on different path's. Any one has idea?


brew install php56 – error: unable to remove file: Operation not permitted

I have a error while trying to install php56.
I'm running macOS 10.12.6

[x] ran brew update and can still reproduce the problem?

[x] ran brew doctor, fixed all issues and can still reproduce the problem?
no issues: Your system is ready to brew.

[x] ran brew config and brew doctor and included their output with your issue?

brew config:
HOMEBREW_VERSION: 1.5.4
ORIGIN: https://github.com/Homebrew/brew
HEAD: 021fe22e3c982b08346422d1e7897e929a709380
Last commit: 11 days ago
Core tap ORIGIN: https://github.com/Homebrew/homebrew-core
Core tap HEAD: 7679dc9b1226235c927bdcf6dfca4d8cbb571b81
Core tap last commit: 19 minutes ago
HOMEBREW_PREFIX: /usr/local
CPU: quad-core 64-bit haswell
Homebrew Ruby: 2.3.3 => /usr/local/Homebrew/Library/Homebrew/vendor/portable-ruby/2.3.3/bin/ruby
Clang: 9.0 build 900
Git: 2.14.3 => /Applications/Xcode.app/Contents/Developer/usr/bin/git
Curl: 7.54.0 => /usr/bin/curl
Perl: /usr/bin/perl
Python: /usr/bin/python
Ruby: /usr/bin/ruby => /System/Library/Frameworks/Ruby.framework/Versions/2.0/usr/bin/ruby
Java: 1.8.0_131
macOS: 10.12.6-x86_64
Xcode: 9.2
CLT: <IP_ADDRESS>.1.1510905681
X11: 2.7.11 => /opt/X11
brew doctor:
Your system is ready to brew.
To help us debug your issue please explain:

What you were trying to do (and why)
I was tryint to install php56 as decribed in this tutorial: https://getgrav.org/blog/macos-sierra-apache-multiple-php-versions
brew install php56 --with-httpd
I already reinstalled homebew.

What happened (include command output)

…
error: error reading '/dev/fd/7'
1 error generated.
clang: error: unable to remove file: Operation not permitted
dtrace: failed to compile script /private/tmp/php56-20180221-46555-z4wo25/php-5.6.33/Zend/zend_dtrace.d: Preprocessor failed to process input program
make: *** [Zend/zend_dtrace_gen.h] Error 1
make: *** Waiting for unfinished jobs....

READ THIS: https://docs.brew.sh/Troubleshooting.html

These open issues may also help:
Installing php55 and php56 makes my mac terminal dead https://github.com/Homebrew/homebrew-php/issues/4602
php56-mongodb _clock_gettime error at runtime https://github.com/Homebrew/homebrew-php/issues/3737

What you expected to happen
I expected php to install correctly

Step-by-step reproduction instructions (by running brew commands)
brew install php56 --with-httpd

We will close this issue or ask you to create a pull-request if it's something the maintainers are not actively planning to work on.

Report this to Homebrew/php (as noted by the issue template).


Include updater in Windows scripts

Including updater in build scripts.
@zanderz I wasn't sure where to include updater in the installer, can we chat about it?
Removed set GOARCH=386 cause it was already at the top of file.

:mag_right: No visual changes found as a result of these commits.

LGTM :thumbsup:, thanks for adding this.
Just let me know what the sequence should be now, instead of what we do now at install:

shut down running stuff
copy the files
write startup shortcuts to do steps 4-6 at boot time for launch
launch service via keybase ctl start
directly launch `kbfsdokan [args]'
directly launch gui

I assume we'll just launch one watchdog. How does it find the gui and so forth?

Instead of ctl start and kbfsdokan:

launch watchdog2 via keybase ctl watchdog2
launch gui


Razor Pages / MVC Authentication Example

Feature request
Is your feature request related to a problem? Please describe.
First of all, thanks for a great project - I have looked at the examples but they all seem to be based off of Blazor WASM. I have started a new project using Razor Pages but there is a lack of documentation around how to do the authentication server side
Describe the solution you'd like
An example project that utilised Razor Pages or MVC pattern.
Describe alternatives you've considered
Looked at existing examples but they are based off of Blazor WASM
Additional context
I've added Supabase as a Scoped dependency following the video linked in the README:
builder.Services.AddScoped(_ => new Supabase.Client(supabaseOptions!.Url, supabaseOptions.AnonKey,
    new Supabase.SupabaseOptions
    {
        AutoRefreshToken = true
    }));

I'm using the PKCE flow for OAuth:
var signInUrl = await _supabaseClient.Auth.SignIn(Constants.Provider.Google, new SignInOptions
{
    FlowType = Constants.OAuthFlowType.PKCE,
    RedirectTo = $"{Request.Scheme}://{Request.Host}/login/callback"
});

Then in my login callback handler:
app.Map("/login/callback",
    async (Supabase.Client supabaseClient, HttpContext context) =>
    {
        if (context.Request.Query.ContainsKey("code"))
        {
            var code = context.Request.Query["code"];

            if (context.Request.Cookies.TryGetValue("PKCEVerifier", out var verifier))
            {
                var session = await supabaseClient.Auth.ExchangeCodeForSession(verifier, code!);

                context.Response.Cookies.Delete("PKCEVerifier");

                var identity = new ClaimsIdentity();
                if (!string.IsNullOrEmpty(session?.AccessToken))
                {
                    identity = new ClaimsIdentity(ParseClaimsFromJwt(session.AccessToken), "jwt");
                }

                var user = new ClaimsPrincipal(identity);
                await context.SignInAsync(new ClaimsPrincipal(user));

                context.Response.Redirect("/");
            }
        }
    });

But when I go to my home page, if I try and get the email for the current user (as an example), its null: _supabaseClient.Auth.CurrentUser?.Email;, however, I can see that I am authenticated as calling this returns true: User.Identity?.IsAuthenticated. So I guess I'm missing a way of provisioning the supabase client with the currently logged in user, any ideas? The reason being is because I have RLS enabled so I want the user to see their data only. Thanks

Sorry for the late reply @CallumVass, busy last couple of days for me.
Yes, that solution is almost exactly how I would’ve approached it. Looks good to me! Thanks for taking the time to work through and post it.

Thanks for the reply, I'll close this now then.


Merge to live 2022-09-01

No detected changes to .json files in the root

OPS passed. This can merge.


Universal renderer: lazy() automatically inserts an empty text node, which may or may not be supported by the underlying renderer

Describe the bug
This is a regression caused by https://github.com/solidjs/solid/commit/c8fe58e9d259e463def62535f6d23454d4f30cee as far as I can tell, specifically packages/solid/src/render/component.ts line 381
return createMemo(() =>
      (Comp = comp())
        ? untrack(() => {
            if ("_SOLID_DEV_") Object.assign(Comp!, { [$DEVCOMP]: true });
            if (!ctx || sharedConfig.done) return Comp!(props);
            const c = sharedConfig.context;
            setHydrateContext(ctx);
            const r = Comp!(props);
            setHydrateContext(c);
            return r;
          })
        : ""
    ) as unknown as JSX.Element;

upon upgrading, our proprietary universal render started to fail in cases where the lazy() element was being used, because we never implemented a version of createTextNode() that would intelligently handle the empty string the second half of that ternary.
Your Example Website or App
n/a
Steps to Reproduce the Bug or Issue

create a universal renderer, and implement createTextNode like so:

    createTextNode: function (_text: string): MyNodeType {
         throw new Error("Text nodes not supported!")
    },

create an HTML with a lazy() component inserted.
Notice your error is triggered

Expected behavior
n/a
Screenshots or Videos
n/a
Platform
n/a
Additional context
So the reason we don't support bare text nodes in our renderer is that all of our text live inside a specific base element, like so:
<label text="my actual text" />

so there was never a need to implement text nodes, and it would muddy the waters of our implementation to try. We can work around this issue just by ignoring bare text entirely. that said, if the implementation of a built in component tried to insert any other kind of text, for any reason, we'd still have this problem. One approach may just be to document this behavior, with wording along the lines of: "your renderer must at least support empty string and whitespace-only text nodes. your renderer may ignore them entirely if desired."

I see. Yeah we needed a fixed marker here. Empty text node seemed the easiest because it is mostly invisible in the DOM.  We do this in things like Portals as well but I suppose you don't hit that in the universal renderer as well. Documenting it might be the easiest option I think. I'm not sure how else to best handle it.


Add hard-coded solution to FizzBuzz

Definitely not the textbook solution :)

Oh god. I knew something like that would eventually happen. I knew it. Still wasn't prepared...
Good job, I guess :')

Is it okay if I link your solution in the readme? I wanna make a Top #5 of personal favorites. yours is def on the list

Haha sure thing it would be an honor :)


WIP: Update Junit/Mockito

Are you open to an aggressive migration to JUnit5? Aggressive meaning to potentially disable non-trivial issues?

Is this the time to avoid container in a unit test anti-pattern?
https://izpack.atlassian.net/wiki/spaces/IZPACK/pages/491531/How+to+use+PicoContainer+with+JUnit

Is this the time to avoid container in a unit test anti-pattern? https://izpack.atlassian.net/wiki/spaces/IZPACK/pages/491531/How+to+use+PicoContainer+with+JUnit

We got a problem with PicoContainer anyway in order to support the latest JDKs. Unfortunately I did not had the time to work on this problem so far.

Yes I see it looks abandoned https://github.com/picocontainer/picocontainer
Please let me know what decision is taken about an alternative and how I can contribute.

I did some trials in using Weld CDI in my separate PR #779, but did not have enough time to work more on this lately...


Make UI components modular for different viewing and labeling scenarios

There are multiple potential related use cases that require viewing and interacting with radar data and tracks, e.g.:

screening output of AI system
labeling from scratch (#22)
formal error analysis or inter-annotator agreement experiment
public facing UI
etc.

These would have different page navigation but similar UI elements.
We could consider wrapping radar display and track visualization into reusable components that could fit into different navigation schemes.
This would be a major refactor and it's unclear to me at the moment whether it's worth it. It depends on how many different things we want to do and how robustly, e.g., are they research "one-offs" or something we want to maintain.

This is still a possible goal. We looked into porting to React and Typescript to help


Complex Table Conversion Issue (Wrong order, key-value regions)

Bug

Out of order conversion: it would be nice if headers(UNCLASSIFIED , American Football Conference (AFC) , AFC East) appear after text fields
Keys missing their values: the text fields have values, but it is all separated by newlines in the text output. it would be amazing if  the text fields had their values more closely associated (something like Code: DLPHN instead of what the output currently shows)

Steps to reproduce

import os
from docling.datamodel.base_models import InputFormat
from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.datamodel.pipeline_options import PdfPipelineOptions, TableFormerMode
from pathlib import Path

source = "input/complex table.pdf"

pipeline_options = PdfPipelineOptions(do_table_structure=True)
pipeline_options.table_structure_options.do_cell_matching = True  # uses text cells predicted from table structure model
pipeline_options.table_structure_options.mode = TableFormerMode.ACCURATE

doc_converter = DocumentConverter(
    format_options={
        InputFormat.PDF: PdfFormatOption(pipeline_options=pipeline_options)
    }
)
result = doc_converter.convert(source)
## Export results
output_dir = Path("resultconversion")
output_dir.mkdir(parents=True, exist_ok=True)
doc_filename = result.input.file.stem

# Export Text format:
with (output_dir / f"{doc_filename}.txt").open("w", encoding="utf-8") as fp:
    fp.write(result.document.export_to_text())

complex input table.pdf

complex output table.txt
Docling version

2.4.0
Python version

3.12.4

Thank you @DAVIDCRUZ0202 !
We will need to update how we detect key-value regions.

to add on, I think there might also be a bug in how docling is not able to label this as a key-value pair. But rather, "Code:" as text and "DLPHN" as text. Is this the expected behavior? If so, I was wondering if there is any way to extract key-value pairs like we do for tables, headers, etc.

I think there might also be a bug in how docling is not able to label this as a key-value pair. But rather, "Code:" as text and "DLPHN" as text. Is this the expected behavio

Hi @mawil21 , while the layout model in docling can identify key-value regions, currently these regions are simply treated as text by downstream processing. The ability to preserve the structure within key-value regions (and forms) is on our roadmap. You can find more details here.


Consider adding an extensions facility for experimental features and non-standard behavior

Feature
As the HTTP API approaches 1.0 status, it may be worth adding a way for admins to enable various extensions within the HTTP API. The extensions list would act as a boolean. If an extension is in the list, it is enabled. If an extension is NOT in the list, then it's disabled. This allows extension stanzas to live in the config file without being active.
This also means the JSON schema for the config file doesn't need to change when new extensions are implemented.
Below is just one example of how this could look:
{
    "http_server": {
        // Expected configuration ...
    },

    "irods_client": {
        // Expected configuration ...
    },

    // Defines the list of extensions enabled in the HTTP API server.
    "extensions": [
        "openid_generic_non_standard_P1234",
        "irods_experimental_feature_auto_create_users",

        // Notice how this extension requires an additional stanza shown
        // below this list.
        "keycloak_non_standard_symmetric_keys_multiple_aud_issue_13823"
    ],

    // Some extensions may require additional stanza. These stanzas
    // WOULD NOT be recognized by the JSON schema. Validation of the
    // config file would just ignore these properties.
    "keycloak_non_standard_symmetric_keys_multiple_aud_issue_13823": {
        "id_token_secret": "xyzabc123"
    }
}

This could be used for non-standard things as well as experimental features created by the iRODS dev team.
Keep in mind that this is NOT a plugin system. Each extension would be part of the HTTP API binary.

Would the extension items become part of the stanza, or would they be like the configurations and not be part of the stanza?
If yes, then we would still need to update it when we add/remove extensions?

The extensions list would be part of the schema. Its contents would not. Those can be arbitrary strings. The HTTP API would ignore elements it doesn't recognize.

And each extension would be fully documented.


Chapter compression

Describe your suggested feature
Chapter compression
Chapter=30MB =>5MB
JPG =>webp
Other details
No response
Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open or closed issue.
[X] I have written a short but informative title.
[X] I have updated the app to version 1.11.0.
[X] I will fill out all of the requested information in this form.

Dude, you opened 7 issues of the same thing, chill out & let things load.
Close out all the issues except #1344, and what about TachiyomiSY's "Data Saver" feature in SY Settings > Advanced

يا رجل، لقد فتحت 7 إصدارات من نفس الشيء، استرخ واترك الأشياء تُحمل. (10 الآن بعد كتابة هذا)
قم بإغلاق جميع الإصدارات باستثناء #1344 ، وماذا عن ميزة "Data Saver" في TachiyomiSY في إعدادات SY > متقدم

I didn't know how to use the data saver

@Smol-Ame
How to use Data saver

@Dragonsballsuper
A

Learn to close out all of your duplicate issues
Learn to Google the services mentioned in said Data Saver setting (like: https://images.weserv.nl/docs/introduction.html)
I don't use it, and from my time in support, it sometimes causes issues with said data saver/compression

@Smol-Ame
These are the settings I use but they only work with azora


Response pane gutters are taking excessive space on screen in Insomnia 9

Expected Behavior
The app should minimize wasted space, allowing users to fit as much important information as possible.

CodeMirror-gutter CodeMirror-linenumbers element should take space for a single-digit number and expand as needed
CodeMirror-gutter CodeMirror-lint-markers element should not take up any space if the functionality is not active

Actual Behavior
When I make a request that returns smaller response, the app UI takes unnecessary space for displaying the response. These elements take too much space.

Is there an existing issue for this?

[X] I have searched the issue tracker for this problem.

Insomnia Version
9.0.0
What operating system are you using?
Other Linux
Operating System Version
Linux arch 6.8.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 17 Apr 2024 15:20:28 +0000 x86_64 GNU/Linux
Installation method
AUR

Hi @DusanLesan thanks for the feedback.
The space is there for visual hints to appear when there are errors or when line numbers grow to triple digits see example

I think the issue about saving space is valid.
I haven't seen a code editor that jumps around as lines get added. That would be a weird experience and a bit surprising to the users.
Looking at how other code editors solve this issue we could add an option to show/hide line numbers from in the app settings.

I haven't seen a code editor that jumps around as lines get added. That would be a weird experience and a bit surprising to the user.

@gatzjames When the new request is made, the whole pane would refresh to display new data and the gutter width would be re-calculated at that time. I would expect gutter increasing in width would not affect rest of the UI and only the pane with the content (space for text in preview would get reduced, but the layout would remain unaffected). I have no idea when these errors are displayed, but I personally would not mind the whole gutter for errors being added or removed as the errors are detected.
Here is what neovim does:

There is a minimum of 3 chars and the linecount space is further expanded as needed.
Note the way nvim notifies about removed lines in git in lower right window: simply change number color. That could be a alternative solution to display those errors
https://github.com/Kong/insomnia/assets/20520590/eb55d45d-5da0-46e3-afbc-c58a0af1a1c1
Even if the code is editable, and the number of lines drastically changes,  I do not find it jarring for the line-number width to change


Have mapproject generate antialised images

mapproject does (bicubic) interpolation. When being used to generate low-res imagery, this of course results in aliasing. It would be nice, per Ben, to add to it the ability to create antialised images.
The same applies to dg_mosaic.
I would argue that this, if ever implemented, should be done carefully or as an option, to not increase the run-time when this is not necessary.
I am not sure how much of a priority to assign to this item. As Ben points out, one can use gdalwarp to do the job.

It is better to mapproject at native resolution (which is auto-determined) then use gdal_translate -r average to reduce the resolution. This is an option in GDAL (that did not exist back then) which should help avoid aliasing.
If several input images exist, it is likely best to mapproject them using the same --tr value first before resampling as above.
Our point2dem can also resample a georeferenced image using weighted average.


Empty array of navPages

Browser:

I'm newbie. I used this guide.
In my md files I used front matter keys like this:
---
title: 11ty starter site
description: This is a demonstration website generated using the 11ty static site generator.
layout: base.njk
eleventyNavigation:
	key: home
	order: 100
---

---
title: About us
description: What we do.
eleventyNavigation:
	key: about
	order: 200
---

---
title: Privacy policy
description: We keep your details private.
eleventyNavigation:
	key: privacy
	parent: about
	order: 220
---

---
title: Our team
description: Information about us.
eleventyNavigation:
	key: team
	parent: about
	order: 210
---

But it return empty array (screenshots above):
{% set navPages = collections.all | eleventyNavigation %}
{{ navPages | dump | safe }}

What's problem with eleventy navigation in my project?
Repository: https://github.com/kalininmax/11ty

Instead of using tabs in your frontmatter, try using 2 spaces:
[{"key":"home","order":100,"url":"/","pluginType":"eleventy-navigation","title":"home","children":[]},{"key":"about","order":200,"url":"/about/","pluginType":"eleventy-navigation","title":"about","children":[{"key":"team","parent":"about","order":210,"url":"/about/team/","pluginType":"eleventy-navigation","parentKey":"about","title":"team","children":[]},{"key":"privacy","parent":"about","order":220,"url":"/about/privacy/","pluginType":"eleventy-navigation","parentKey":"about","title":"privacy","children":[]}]}]

@pdehaan thank you so much.
Actually, just now, I found this answer in Eleventy Walk Through guide. But anyway thank you for your time.

FWIW it looks like this occurs because of this condition. If you do not provide a specific key to eleventyNavigation, then the pages in the collection you pass cannot have a parent. Not sure whether that is intentional, but it was unexpected to me.


Error codes don't seem that helpful for user or us

Are they functional in any way? I've only seen 0, which "feels" like it's not real.

We don't expect users to often see errors, but if they do, it is worth knowing the code. However if it does not fit with copy preferences, it can be removed.

It's not so much I'm averse to showing a code. It's just that 0 as an error code doesn't feel real. I know it's silly, but 321 would feel more real.

Removed codes, show link to bug page instead.


Fix NuGetPack target.

Use properly scoped version variable.

@bgrainger The first commit fixes the NuGet build. The other two are workarounds for Xamarin.iOS and Monotouch bugs in the current code. I have no objection to splitting these into 2 or 3 PRs if you'd prefer, but as it is, one PR is a faster turnaround cycle.


Electrum-XZC 'cannot deserialize transaction' error

Hi.
When i try to import my wallet (using it address or private key) into Electrum XZC, i got the following error message during wallet synchronization:
20200806T043748.857555Z |    ERROR | electrum_xzc.interface.[electrumx.zcoin.io:50002] | Exception in wrapper_func: SynchronizerFailure('cannot deserialize transaction a55993253f0bda754dd4a4699643fb56f5c36f85fbfa900e3c7215e5f2e0345a',)
Traceback (most recent call last):
  File "electrum_xzc\synchronizer.py", line 224, in _get_transaction
  File "electrum_xzc\transaction.py", line 728, in deserialize
  File "electrum_xzc\transaction.py", line 591, in deserialize
electrum_xzc.transaction.SerializationError: extra junk at the end

So, the wallet balance on https://explorer.zcoin.io/address/a4stPFsQPS7fHUFxawtTATTYA91g41bDff is 7.04885703 ZCOIN and in Electrum-XZC is 0 ZCOIN, and transaction 'a55993253f0bda754dd4a4699643fb56f5c36f85fbfa900e3c7215e5f2e0345a' is missing from transactionHistory.
See program log for additional info:
electrum_log_20200806T043741Z_7008.log

Now it is parsed correctly.


self.rotation_degrees doesn't work with 180/-180 -> 180 rotation is 179.999985

Godot version
3.5.2
System information
MX Linux, i5-6500
Issue description
Hey,
I'm building stairs for a dungeon crawler and want to check the rotation_degrees value of the stairs themselves.
If they are of a certain value the player is teleported to another place, that makes it possible that I can use the stairs for all possible rotations (0, 90, 180, 270)
This works fine except for 180/-180.
To investigate the issue I printed the rotation_degrees and in the case of 180/-180 it displays 179.999985.
I can workaround the issue but I thought this is not the expected behavior.
Steps to reproduce
Look at the Stairs.gd, the stairs that doesn't work is the one with the cube, the other stairs are there to show how it works properly.
Minimal reproduction project
stairs_bug.zip

This is known as floating point accuracy. Never expect exactly 180 degrees.

What is the exact value returned by those cases? They are probably just slightly off as well but since they are slightly over 90 and 270 they seem more correct
For reference in 4.0 the results from 90, 180, and 270 degrees are:

90.0002059936523
179.999862670898
270.000061035156

None of them are exactly "correct"

Also the error comes probably from the conversion from degrees to radians, try setting the rotation in radians and see if anything changes

What is the exact value returned by those cases? They are probably just slightly off as well but since they are slightly over 90 and 270 they seem more correct
For reference in 4.0 (not sure about the differences because of precision, and using 2D nodes here) the results from 90, 180, and 270 degrees are:
* `90.0002059936523`

* `179.999862670898`

* `270.000061035156`

None of them are exactly "correct", and the error for 90 is bigger than that for 180

It is printed as 0, 90 and -90. Maybe the culprit is indeed that they are slightly off but higher.

Also the error comes probably from the conversion from degrees to radians, try setting the rotation in radians and see if anything changes, and consider that using radians rather than degrees is usually going to give you more accurate results

I never used radians but you mean something like:
if deg2rad(self.rotation_degrees.y) == deg2rad(180):
instead of
if self.rotation_degrees.y = 180
That actually works.
My workaround in the beginning is:
if int(self.rotation_degrees.y) == 179:
self.rotation_degrees.y = 180
If it is set from code, it also works

No I mean self.rotation = PI, assigning with radians
Also what do you get from print("%.16f" % self.rotation_degrees.y)? For values like 90 and 270

It is printed as 0, 90 and -90

Note that printing has low precision, floating point numbers with slight deviations could very easily display as something else if you just print them without any formatting. So be very careful when relying on that information.

Also what do you get from print("%.16f" % self.rotation_degrees.y)? For values like 90 and 270

Note that printing has low precision, floating point numbers with slight deviations could very easily display as something else if you just print them without any formatting. So be very careful when relying on that information.

This is what I got.
0.0000000000000000
90.0000000000000000
179.9999847412109375
-90.0000000000000000

yes

For 270 degrees yes but it's -PI/2 for -90

Alas, it also didn't work

That doesn't make sense, what is it in degrees?

in the case of PI/2 and -PI*1.5 it is 90°
or:
elif self.rotation.y == PI/2 or self.rotation.y == -PI*1.5:
vs
elif self.rotation.y == 90 or self.rotation.y == -270:

For these purposes you should probably use approximate equality, but I mainly was suggesting assigning radians and not degrees

For these purposes you should probably use approximate equality, but I mainly was suggesting assigning radians and not degrees

Is this possible from the inspector? If not it would not really benefit my workflow, since I can workaround it pretty easily. Set from code it works flawlessly (and in most other cases also) It's just weird that it's 90.00..., 270.00..., 0.00... but 179.99...

Units aren't configurable in the inspector, but I doubt it would be convenient to write out units in radians anyway (even if you could use the PI and TAU constants in an expression).

For the case of inspector see #74313 and #20616


Load images when WLAN active

Is your feature request related to a problem? Please describe.
I have disabled the loading of images because mobile bandwidth is expensive in Germany. So I download images manually (tap the "show pictures" button), e.g. when getting ebay search result lists. However I have to do this at home too, although this shouldn't be needed.
Describe the solution you'd like
I'd like to have an additional setting in the dialog below "[x] always load pictures when WLAN active"
Describe alternatives you've considered
Changing the settings each time when leaving home / returning home.
Additional context

Both twitter and instagram have settings related to mobile bandwidth, so my idea isn't that wild.

Duplicate of #1502
Note: Not automatically loading images is mainly a privacy feature. Many email senders use images to track who has read their emails and when.


Broken command in flannel_multi_node_cluster instructions.

This is a Bug Report

Problem:
Command to add the .json file to etcdctl fails.
Proposed Solution:
I think the line
etcdctl set /coreos.com/network/config < flannel-config.json
should be
etcdctl put /coreos.com/network/config < flannel-config.json
Page to Update:
https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/

https://kubernetes.io/docs/getting-started-guides/fedora/flannel_multi_node_cluster/ has gone
Based on that, I intend to:
/close


useMethods methods object is not stable and changes when initialState is changed

What is the current behavior?
The useMethods hook wraps the behaviour of useReducer to return a nicely typed methods object.
https://github.com/streamich/react-use/blob/0fabbcd641e5fc6d16091e7c4c803efe80d7ff56/docs/useMethods.md#L44
However, the methods object returned from useMethods is not stable and changes whenever the initialState argument changes.
This does not match how React treats an initialState argument for useState and useReducer

The initialState argument is the state used during the initial render. In subsequent renders, it is disregarded. (https://reactjs.org/docs/hooks-reference.html#lazy-initial-state)

This also does not match how React guarantees the setState method from useState and the dispatch method from useReducer to both be stable and not to change on re-renders or when initialState changes.
What is the expected behavior?
I would expect that the methods object was guaranteed to be stable and not to change on re-renders or when initialState changes. (Though I would expect it to change if the createMethods argument changed)
This would then match the behaviour of the setState method from useState and the dispatch method from useReducer.
Investigation
Looking at the source of useMethods.ts, I think the current behaviour is unintentional.
For example, the dispatch behaviour is already stable, since createMethods is re-run for each dispatch call:
https://github.com/streamich/react-use/blob/0fabbcd641e5fc6d16091e7c4c803efe80d7ff56/src/useMethods.ts#L19-L24
But the way that the wrappedMethods object is created introduces a dependency on initialState:
https://github.com/streamich/react-use/blob/0fabbcd641e5fc6d16091e7c4c803efe80d7ff56/src/useMethods.ts#L28-L35
I think the bug was introduced accidentally in https://github.com/streamich/react-use/commit/b394f3d72356d331dbce48acd3686bbb64d331b5, since it wasn't present in the original version of the hook.
Version Info

OS: Windows 10
Browser: Chrome 83
React: 16.13.1
react-use: 15.2.1, >=13.26.0

Faced a simillar issue, where the methods object was changing on each render because of the initialState.
function SomeProvider({ children, data }) {
  const [state, methods] = useMethods(createMethods, { ...INITIAL_STATE, ...data });

Was able to fix it by memoizing the initialState as
function SomeProvider({ children, data }) {
  const initialState = useMemo(
    () => ({ ...INITIAL_STATE, ...data }),
    [data]
  );
  const [state, methods] = useMethods(createMethods, initialState);

Also affected.

Looks like they fixed this in the master:
https://github.com/streamich/react-use/blob/master/src/useMethods.ts

I opened a PR fixing it: https://github.com/streamich/react-use/pull/2458


Implement plotly dash integration

Would love to see a dash component for rosely so it could be used in Dash dashboards

Hi @ananmaysharan thanks for the suggestion. I'm not too familiar with Dash but taking a quick look it appears that this could be done easily by feeding the figure created by Rosely to the Dash API which is shown in a short code snippet here in this tutorial.
Just in case you were not aware you can return the ploty figure from Rosely like so:
# WR is a plotly.WindRose instance
fig = WR.plot(output_type='return')

You can then send that to Dash following the tutorial and using their API pretty easily.
It appears that Rosely has been used with Dash dashboards in this project: https://github.com/romarowski/local_air_quality_dashboard


Add "excludes" to Intent

Excluding one or more entities will cause a match to fail if any of those entities are present.

Hope this one isn't forgotten, still looking forward for it :)

fingers crossed this one was closed accidentally :crossed_fingers:

I haven't had the time to get this over the finish line 🫤

@JarbasAl @goldyfruit Can you link some examples of this being used to confirm things function as expected? I don't see any unit test coverage so I'd like to see some examples of how its working

@JarbasAl @goldyfruit Can you link some examples of this being used to confirm things function as expected? I don't see any unit test coverage so I'd like to see some examples of how its working

Some tests coverage are already in the PR :1st_place_medal:

Thanks @NeonDaniel :+1:

Looking at the automation, this may also need a version bump in the PR.. I also see tests should have been triggered on PR so I'm not sure why that didn't happen

Some tests coverage are already in the PR 🥇

Excited to see this getting some traction again! While the test added provides coverage for the full integration of excludes into IntentEngine, I was also hoping to seem something more targeted that flexes Intent.validate with exclusions, similar to what we see in IntentTest.
I think I've reasoned my way around how this will interact in a system with many intents (it should be relatively isolated to itself, though with the expected vocabulary comingling).
Also, +1 to @NeonDaniel 's note that we need a version bump here.


Build error after adding the gradles

Task failed with an exception.

What went wrong:
Execution failed for task ':app:mergeDebugNativeLibs'.

Could not resolve all files for configuration ':app:debugRuntimeClasspath'.
Could not find com.github.anggastudio:Printama:0.9.7.
Searched in the following locations:
- https://dl.google.com/dl/android/maven2/com/github/anggastudio/Printama/0.9.7/Printama-0.9.7.pom
- https://repo.maven.apache.org/maven2/com/github/anggastudio/Printama/0.9.7/Printama-0.9.7.pom
- https://jcenter.bintray.com/com/github/anggastudio/Printama/0.9.7/Printama-0.9.7.pom
Required by:
project :app

Can you give me more detailed information.
I think I should remove maven installation.

close this due to lack of information of the issue


Added solutions 25.3

Please merge

Please merge if you don't find any discrepancy.. or tell me if you want something added.

thanks so much


Rename PostgresConnector to AiopgConnector

This issue suggests renaming PostgresConnector to AiopgConnector, for a more explicit class name. And we may want to add Psycopg2Connector or AsyncpgConnector in the future.

The main downside I can see with supporting multiple libs is that if we don't make one "the official one", pip install procrastinate won't be enough to install Procrastinate on its own.
I guess we only have two options here:

Choosing an official connector (AiopgConnector for now, as it's the only one :) ), and requiring the corresponding dependencies by default
Or explicitly telling people to choose an extra dependency when installing Procrastinate

I think I have a favor for the second one, as forcing people to install dependencies they don't need doesn't seem like a good idea. Especially big binary dependencies like DB drivers.

(the 3rd possibility which I don't support but would be possible is to manage each backend in its own package)
We'll need a dedicated error message when we import and it fails.
If possible, I'd like to avoid too much code running at import time.

I am also in favor of option 2 (tell people to choose an extra dep when installing Procrastinate). But no need for this extra dep until we support another driver I guess.


output for random field cannot be shown in paraview when structural elements are involved

output for random field cannot be shown in paraview when structural elements are involved
the output for for example the "YOUNG_MODULUS" parameter is full of nans and ifinites in the vtk file.
this is probably a Kratos Issue

https://github.com/KratosMultiphysics/Kratos/pull/12417

related to #136


chore: Use Parity 2.7.2

Tested and working fine. I'd do a (last?) release after.

Merging as insubstantial. We should test the release when the CI is done.