Cargo should understand distinctions between public/private dependencies

Current report
Dependencies for crates today can be separated into two categories: those that are implementation details and those whose types are present in the public API of the crate. Cargo does not support distinguishing these two cases today, but it can often be crucial for dependency management.
If a dependency is an implementation detail (i.e. no types are exposed) then it can be easily duplicated in the dependency graph without worry (other than concerns like binary size). In other words, Cargo's safe to have multiple semver-incompatible versions of this dependency because they won't talk with one another.
If a dependency is part of the public API, however, then it's critical that any crate which can share this type it needs to all be of the same version. In other words, Cargo's logic of allowing multiple semver-incompatible versions is almost always guaranteed to go awry.
If Cargo were to understand a distinction between these private/public (or internal/exposed) dependencies then it could solve problems like:

Provide much nicer resolution error messages rather than relying on the compiler to figure this out.
Restructure the crate DAG to ensure that dependencies which work with multiple major versions end up working with other crates that only require one major version.
Ensure that crate resolution never picks too many versions of a crate and instead forces common dependencies to all have the same version.

Original report
Cargo is overeager to pull in multiple copies of a crate
Say we have a crate with the following Cargo.toml:
[package]
name = "foo"
version = "0.1.0"
authors = ["Steven Fackler<EMAIL_ADDRESS>
[dependencies]
postgres = "0.9"
r2d2_postgres = "0.9"

r2d2_postgres version 0.9.3 depends on postgres version 0.10, while version 0.9.2 and lower depend on postgres version 0.9. Cargo would ideally pick r2d2_postgres version 0.9.2 and postgres version 0.9.6, but it instead picks r2d2_postgres version 0.9.3, which pulls in postgres version 0.10, as well as postgres version 0.9.6. This ends up totally blocking any use of these dependencies.
This issue rather significantly impedes crates' abilities to upgrade their dependencies.
It seems like Cargo's resolution logic should have the property that if there exists a resolved dependency graph with no more than one copy of each dependency, it should never pull in more than one copy of a dependency. Unfortunately, questions like "does such a resolved dependency graph exist" are NP-complete, but I suspect that it's tractable in practice (we don't expect crates to be randomly permuting their dependencies every minor version, for example).
In the meantime before someone has a chance to integrate a SAT solver into Cargo, I think there are some things we can do to help users correct Cargo when it fails to resolve things "properly". For example, cargo update could warn whenever it has to pull in multiple copies of a crate, identifying the portion of the object graph that forced that to happen. This should provide users an easier starting point to poking the graph into shape with cargo update --precise.

The SAT solver reference was not a joke btw - the yum package manager uses a SAT solver to do its job.

Yeah I've been worried about this in the past as well. Right now the resolver is kinda just a pile of heuristics and then it returns the first solution it always finds (despite there being many, in situations such as this).
It may be the case that we could avoid a full SAT solver by applying smarter heuristics for the time being (e.g. we'd need some sort of "scoring system" for any solution from a SAT solver anyway), and that may also keep the resolution stage speedy.

cc @wycats, curious on your thoughts about this

Yeah, the scoring system is what I'm most unsure about. It should prefer newer versions of libraries to older versions and try to minimize the number of copies of dependencies, but how those should interplay and factor into the solver seem like pretty nontrivial questions.

I also noticed that, with a setup like:
[package]
name = "foo"

[dependencies]
bar = "*"
libc = ">= 0.1, < 0.3"

[package]
name = "bar"

[dependencies]
libc = "0.1"

cargo will pull in multiple copies of libc at version 0.1 and 0.2, even though the requirements can be satisfied with just 0.1. (Same issue happens with a wildcard dependency.)
Is that the same issue as here? It seems related but like a fix might be different.

Yeah I think it's basically the same issue as this.

I think this issue really limits the usefulness of dependencies in crates and makes life hard for library authors. Particularly, it makes it dangerous to use any types in your public API that are defined by another library.
To use these types in your public API, users must add the other library as one of their dependencies. The hard part, however, is that if these dependencies are at different versions it won't compile.
For example, my objc crate works fine with either libc 0.1 or 0.2. I described the dependency as such in my Cargo.toml and assumed that being more widely compliant would be best so that the dependency doesn't conflict with other libraries that require a specific version. However, what's happened is that cargo always chooses to satisfy that dependency with 0.2, even when the user is using libc 0.1, resulting in a conflict and compiler error.
The result is that, currently, you're forced to choose a specific version for your crate and make the user use it, as well. If a dependency releases a new version, allowing use of it requires dropping support for the old version and publishing a breaking change, splitting your users and meaning the older versions stop receiving updates. This is frustrating for users, because they must ensure all their dependencies use the same version of a crate and they will have to update their dependencies more often as there are more frequent breaking changes.
Not to get melodramatic, but I think easing these multiple version issues will be important for rust and cargo to be pleasant to use in the future. I'm hoping this issue is on the radar of folks smarter than me and is being thought about, sorry if this turned into a bit of a rant.

@SSheldon I believe people should be able to force the use of specific versions with cargo update -p NAME --precise VERSION, fwiw. (Not as nice as changing cargo's behaviour, but it does mean things shouldn't be fundamentally breaking/require dropping support.)

@huonw yeah, it can be avoided if you're careful with your Cargo.lock. Though libraries are recommended to not commit that, so each new user would have to be required to do this.
Maybe another that'd help here would be a way to say in your Cargo.toml, for example, "I want to use the objc crate and I want it to use libc 0.1"? Currently I don't know of any way to do that besides overriding the Cargo file of your dependency.

I've been playing with hooking the Z3 SMT solver up to rust recently and realized this bug exists in cargo, so I sketched out a little semver-solver using it. I know it's a bit like breaking a walnut with a tank (Z3 is a sort of intense 14MB C++ library) but since Z3 (as of v4.4.1) also contains a numerical optimizer it's really trivial to express a mixed constraint-solving / optimization problem with it. It's just a bit of plumbing, maintaining a mapping from packages to Z3 terms, package-versions to integers, and expressing version constraints as integer inequalities on the terms.
Code's here: https://github.com/graydon/z3-rs/blob/master/tests/semver_tests.rs#L158-L267

That's awesome!

SUSE's ZYpp uses libsolv. Yum might also switch to it in DNF. It's only 1.2MB of C, so it's smaller than Z3 :)

For what it's worth, the problem of supporting duplicates makes the exact constraints (and their weights) a little bit more complicated than the usual approach to this problem.
In most versions of this problem, dependency "conflicts" simply fail to resolve, but we have another option available to us. That said, over time, I've increasingly come to believe that we were too willing to use that solution in Cargo, and we'll probably ratchet down our usage of allowed-duplicates somewhat.

Yeah, I think cargo casually permitting multiple copies of a dependency in a project is ... a dangerous default. It needs to be permitted (and we engineered the symbol mangling scheme to explicitly support it) but it's also relatively likely that any given instance of it is a bug. A potentially-very-subtle bug, like "two instances of a library that both think they are in charge of talking to OS subsystem / native library foo"
I think it should probably default to not-working, and require opting in. Though it might also break the ecosystem today if you set that to be the case. I'd be interested to run the experiment on the existing package set, see how many of them can't build with their existing dependency declarations, and if so how much work it'd take / how many duplicate-opt-ins or dependency-range-adjustments to fix.

@graydon I think it's a little more subtle than that.
"Shared" dependencies (dependencies whose types are used in other pub types, or which are transported to other crates through type inference) must not be duplicated.
"Internal" dependencies (dependencies whose types are only used internally) can be safely duplicated (but you might not want to for other reasons, like binary size).
We've talked some about how packages could say that a dependency was "internal", which would then permit duplication and error out if the type was actually made public. Even if we could perfectly detect this, it would still be important to explicitly opt in, because switching from an "internal" to "shared" dependency would be a breaking change to downstream crates.

Hm. I think either we're talking past each other, or I disagree with your interpretation here, or something's changed I don't understand in the problem space. As far as I know (and as it was initially designed), if crate X exports type T, two copies of X (with the same or different versions, doesn't matter) can both be imported independently in the same composite crate w/o any linkage or type system problems. Their types should be given independent, disjoint identities in any composition of them.
The risk is only, as you say, in binary-size and (imo more seriously) violating uniqueness assumptions each copy of X might assume, such as "I'm the one that calls the init routine on a C library I'm linked against" or "I'm in charge of handling sigusr1" or whatever.
If I'm wrong about this, something has .. significantly changed in the design. What part do you think goes wrong?

Here's a simple example of the problem I'm talking about:

a time crate exports pub struct Time { ... }
a format_time crate depends on time and uses time::Time in its signatures
a fancy_time crate provides helpers for producing a time::Time

Now let's say another crate (datetime) depends on format_time and fancy_time. If it tries to pass a time::Time provided by fancy_time into format_time, they better be talking about the identical type.
It's possible for datetime to see two different time::Times and that part will work fine, but one of the primary goals of package naming and versioning (perhaps the primary goal) is to make it possible for humans to compose packages like this and have any hope of things working.
In this case, both fancy_time and format_time are treating the time dependency as a shared dependency, which is the most direct way I know of expressing this constraint ("they better both be talking about identical types").

Ok, that's .. definitely an instance where you'd want non-duplication. And I can think of others! I mentioned some above. But it's not a hard requirement of any of the parts in the system that "public types" implies "can't duplicate", right? I'm just trying to get clear on what you're arguing. Last time I discussed this (in the context of linkage), I was assured that cargo passed a disambiguating sort of name/ver/source triple of metadata to rustc for each crate in a project, such that two copies of the same symbolic-named crate wouldn't clash at metadata-load or link time. I hope that's still true, even if I think it should not be the default behavior.
To be clear on what I'm arguing:

I think probably most users think shared resolution is already happening, consider duplication a bug
I think you could run the experiment on crates.io to see how badly things break defaulting to shared
If there's not much breakage, consider making it default
If there's a lot of breakage:

I suspect it's because of semver misuse as much as anything
I suspect downstream users will also be sympathetic to fixing semvers / opting in to duplication in cases they can't work around it
If it's too painful to set as a default, I think it should at very least become a noisy warning. Binary size alone makes it worth mentioning, and I think there are serious and subtle bugs that come along with it.

I was assured that cargo passed a disambiguating sort of name/ver/source triple of metadata to rustc for each crate in a project, such that two copies of the same symbolic-named crate wouldn't clash at metadata-load or link time.

Yep. Cargo will do that so there won't be any linker errors, but you will run into compile errors like "Expected type foo::Bar but got type foo::Bar" when the two versions of libfoo end up interacting.

Right. Exactly what I'd expect! Good.
Also deeply confusing to any user, no doubt, who didn't ask for it. Hence why I'd make it default to not happen :)

But it's not a hard requirement of any of the parts in the system that "public types" implies "can't duplicate", right?

No part of the system mandates this, but if connected parts of the dependency graph get ahold of same-named types from different versions of the same crate, you'll end up with dependency graphs that resolve but can't compile.
That's possible today, but a long-term goal of mine for Cargo is to make resolves-but-does-not-compile errors impossible (or at least as close to impossible as we can manage).

I think probably most users think shared resolution is already happening, consider duplication a bug

Right, but where sharing is not required, because a crate is used purely internally, allowed duplication is a very nice property to be able to opt into. In my opinion, "this crate is being used purely internally" is the nicest way to express what you mean in a way that Cargo/Rust can help you with. It will also mean that future mistakes (or contributions!) that change the assumption of "internal only" have a prayer of being understood as take mistakes they are.

If there's not much breakage, consider making it default

I totally agree that we should consider making it the default. I think we may be in violent agreement. The main thing I'm arguing is that the opt-in should be of the form "I'm using this crate internally" and not "allow duplication", which is an easy knob to smash on, but doesn't communicate the real constraint very well.

I think there are serious and subtle bugs that come along with it.

I strongly believe that we can decouple the bugs caused by inappropriately sharing dependencies from concerns like binary size (which are also very real).

if connected parts of the dependency graph get ahold of same-named types from different versions of the same crate, you'll end up with dependency graphs that resolve but can't compile

Can you spell out a (further) example of this, just for the sake of my understanding? I'm not sure what exactly it means and I suspect it's important!
Sorry for all the back and forth, I really appreciate you illuminating the topic. The set of ways this stuff can go wrong (not to mention set of ways users need legitimate escape hatches / variable behavior) is .. extensive!

Can you spell out a (further) example of this, just for the sake of my understanding?

A recent example of this was a seemingly-minor change to the libc crate: We made a "minor change" (iirc, making the char typedef unsigned by default on some platforms) which reasonably qualified as a bugfix. But the libc crate was used by a huge number of other low'ish level crates, including use inside of other public structs.
Duplication meant that there were now multiple versions of libc::c_char floating around as people starting to upgrade their libraries to the new dependencies. If a struct containing a 0.1.x c_char was used with a library expecting a 0.2.x c_char, it quite often resulted in a compilation error.
The real problem here was that all of these crates were sharing c_char, but Cargo was (implicitly, in the current semantics) treating them as internal dependencies, allowing them to be freely duplicated.
I agree with you: the default should be "shared" if we can get away with it, and people should opt in to "internal" only if they are willing to make that commitment and expressly want to allow duplication as a conflict resolution strategy. At the same time, we should provide at-least-lints that help detect dependencies that are declared internal but are actually shared.

Oh ok, this is just an example of duplication gone wrong. I thought you meant "resolve but don't compile" meaning "resolve to a shared version, but don't compile". I think that can also happen if, for example, the semver constraints are wrong. I was wondering if you meant that. Anyway, yeah, I think this is all violent agreement :)

Oh ok, this is just an example of duplication gone wrong. I thought you meant "resolve but don't compile" meaning "resolve to a shared version, but don't compile"

Ah, in this case I just meant: "the dependency resolver succeeds, but the resulting dependency graph fails to compile", which is a general class of errors I think we can eventually avoid (with some work).

Anyway, yeah, I think this is all violent agreement :)

Yay!

@kmcallister apparently just implemented a pure rust sat solver. Maybe it could be used here?

Sadly, that's just an interface to an external SAT solver (or a family of them -- those that speak DIMACS input format), not a solver itself. It's similar to the thing I built to talk to Z3, except running out-of-process and just solving, not optimizing. Z3 also speaks DIMACS input format, but again, that format doesn't express optimization problems so it's kinda not ideal (you have to run the solver in a loop crawling towards an optimal solution). The semver test I put in the Z3 repo offloads all the optimizing to the solver itself.

Even if the real solution to this is hard, can we make some warnings or something in common cases. I just wasted like 4 hours not realizing I had 2 versions of serde in my project causing a trait not implemented error.

Is there something an outsider like myself can do to help move this issue forward? Perhaps finding an appropriate solver to use internally, or running the shared-only experiment on crates.io that @graydon suggested, or even just implementing a warning like @nixpulvis mentioned?

I certainly think a warning when updating the dependency graph would be appropriate at least in the short term. I'd probably phrase it as a "by the way" kind of message rather than "OH NO" kind of message since there are may cases where multiple versions can and do coexist peacefully. It pops up pretty frequently with things like bitflags and byteorder.
Further experiments with solvers and objectives also seems like some work that would be great as well. A cargo-update2 or whatever binary crate that could be used in place of normal cargo update would be a great way to experiment with this kind of thing.

Great! I'll start on the warning message to get familiar with the codebase. Once that's done, I can start looking at some of the more complex parts, like using external solvers.

While waiting for cargo itself get something like that, I submitted a PR to cargo-tree which at least shows such issues (and where they come from). A quick debug tool for people affected by this issue.

It would be even more awesome if Cargo could detect that a crate publicly exposes types from a dependency crate.
If so, then the versions of the that

It would be even more awesome if Cargo could detect that a crate publicly exposes types from a dependent crate. Let's call a dependency that re-exports part of the crate a "public dependency".
If so, then the versions of the depended-upon package should be the same between all packages that publicly depend on it, in the part of the dependency tree that is bounded by the absence of public dependencies on that package (either because the dependency is private, or because there's no dependency at all).
That would solve the diamond dependency problem in the situation where multiple crates depend on a shared package, let's say time, and they expose part of that crate's API in their own API. Cargo would then be able to select an appropriately matching single version across all packages that need to share data structures from a crate, yet be free to pick a different version in a different part of the dependency tree.
Of course, the shared version that is picked is subject to the union of all version constraints.

More than just versions, the feature set of each crate is another property of each imported crate that better identical when shared.
Though in this case, cargo should just give an error/warning message, as we probably shouldn't randomly add/remove features just to fit the dependency graph...

Just pitching in here after a somewhat lengthy discussion about nested and flat dependency models in #rust-beginners, that eventually led me to this thread.
Assuming that there is no better solution to make two otherwise non-compatible versions of a library interact with each other - I'm very new to Rust, so I have no idea if there is - @rix0rrr's suggestion of analyzing for exposed dependencies seems like a good idea to me.
The ability to internally use conflicting versions of dependencies greatly helps to build a modular ecosystem, as it removes the exponential increase of "dependency conflict risk" for every dependency you add to your project - something that has historically led to the emergency of monolithic libraries and frameworks (and a lot of wasted effort as a result).
I understand that Rust isn't quite as 'loosely defined' as eg. JavaScript and so it can be hard to implement a dependency model like that of NPM directly, but making a distinction between 'public' and 'internal' dependencies seems like it'd provide the best of both worlds.

Aside from this, another topic discussed on IRC was how to deal with compatible structs across otherwise incompatible versions of dependencies. This idea already have been implied in the posts above, but I'm going to spell it out anyway, if only for the benefit of other beginners stumbling upon this thread:
Say that there is a dependency called awesome_time that exports a Time struct, and also provides a from_unix_timestamp method. Now say that there is an awesome_time@1 and awesome_time@2 version - the major version bump is due to the signature for from_unix_timestamp having changed, but the Time struct is still the same.
Obviously if different libraries use different major versions of awesome_time, they will still be dealing with the same Time struct signature, and the user will want to be able to exchange Time structs between different versions of awesome_time. The solution in this case would be to not include the Time struct into the awesome_time library at all, but rather publish it separately as an independently versioned package (time_struct), and making both awesome_time versions depend on it.
Combined with the suggestion of analyzing "public/exposed" vs. "internal" dependencies, this could result in the following conclusion:

time_struct is an exposed dependency, and only one version may exist.
awesome_time@1 and awesome_time@2 are internal dependencies, and can safely coexist.

In this case, even if "exposed dependency conflicts" were explicitly disallowed, things would still work out fine.
This would not cover the case of time_struct gaining a major version bump, but that would be a relatively rare case - and can perhaps be covered by analyzing where dependencies are exposed, and allowing conflicting exposed dependencies as long as they exist in isolated parts of the application.

I've rambled on a bit and this might be too complex to implement in the short term (if at all possible - again, I'm very new to Rust, so the constraints of the language and compiler are not entirely clear to me yet), but I figured it'd be worth bringing up.

@joepie91 thanks for the writeup! That all sounds like it's aligned with the plan for an eventual set of public dependencies and private dependencies, which this issue is sort of a misleading placeholder for at this point :)

@alexcrichton Hehe, indeed. Unfortunately, it does not appear that GitHub has a way to have a "current thread status summary" feature, short of shoehorning it into the initial comment. That might be a good idea, though, even if just as a brief indicator that the focus of the thread has shifted?
Or perhaps branch off into a new issue specifically about the distinction between exposed/internal dependencies? For what it's worth, I do think "exposed/internal" would be clearer terminology than "public/private", as the latter might imply either secrecy (like a "private upload") or the ability/need to explicitly define it (like a "public member").

@joepie91 good point, I've updated the title and description.

@alexcrichton Are you actively working on this P-high bug?

@brson not currently, I'll remove from P-high for now.
cc @wycats

Just throwing in my 2c worth of bad experience with this issue:
A couple of days ago, I ended up building multiple versions of hyper, because iron re-exports a bunch of its types, but I also wanted a macro that is only exposed by hyper itself. I unwittingly used a newer version of hyper than the one my version of iron was re-exporting from, and ended up spending half an hour chasing a spurious type mismatch because I was trying to mix types from different versions of hyper.
I initially assumed that I had misunderstood the semantics of re-exports, because rustc was effectively telling me "these are different types" without understanding the context of why they were different types. I thought I was going crazy.

Before a proper solver is integrated, could this be partially solved with a heuristic? or deduplication after resolving?
Currently for me it fails on a trivial case where there is only one "conflicting" package and >= 0.2.0 and 0.4.0 are resolved to two different versions.

@pornel I do believe so, yes, but it may be pretty non-trivial to implement (haven't thought too deeply)

I'm just chiming in because I recently discovered that cargo will silently compile multiple versions of the same crate into the same binary, and this feels weird and scary to me, and I see that a warning was proposed but rejected.
I'm concerned that it doesn't seem like people are necessarily all on the same page with respect to @graydon's objection, which I (a total Rust outsider, I grant you) completely agree with -- it's not necessarily safe to link a crate twice EVEN if the linkage is private, and if it's not safe, the resulting bugs will be very subtle at best.
I like @graydon 's example of "two instances of a library that both think they are in charge of talking to OS subsystem / native library foo", which is disastrous EVEN if there's no type clash for the linker to detect because both copies are private. The best example I could come up with was a logging crate -- suppose that it by default opens a logfile whose name is, say, the name of the binary it's in, plus some other stuff (the string ".log", the current time, the pid, etc.) Then two private copies of the crate will open the same file, and the resulting behavior will be the worst kind of totally inexplicable, and probably someone will tear their hair out for weeks trying to debug it.
The pull request for the rejected warning mentioned that the sys crates are "highlanders" -- they enforce non-duplication -- and that servo has a tool for catching duplicate crates. This seems like evidence to me that some important cases require avoiding this currently-unavoidable behavior.

So there's been some breakage this weekend with the release of openssl-sys 0.9.0, due to the requirement that native libraries are linked by only one crate. Any package that depends on git2 ^0.4 no longer builds out of the box due to two versions of openssl-sys being pulled in. Can we get a SAT solver already pretty please? :)

Some interesting discussion of these issues: https://research.swtch.com/version-sat

A question about the openssl-sys case -- do we actually need a SAT solver to fix it, or would ad-hoc adjustment to use the highest version of the dependency have been sufficient? (That is, did the package depending on the lower version specifically exclude the higher?) It sounds from @sfackler's link like other systems may perform this ad-hoc adjustment (and that it is in fact necessary to solve the non-NP-complete case correctly.)

Any progress on this in 2017? It just came up again for one of Ruma's users who ended up with three different versions of a public dependency in their program and resulted in confusing error messages. Does this issue fit into any of the 2017 roadmap issues? Better error messages from the compiler, which make it clearer that there are conflicts between versions, could go a long way in helping new users figure out what the problem is before there is a more formal solution to public/private dep management with Cargo.

I believe https://github.com/rust-lang/rfcs/pull/1977 is being relatively actively worked on.

https://github.com/rust-lang/rfcs/pull/1977 has been accepted, and there is now a tracking issue: https://github.com/rust-lang/rust/issues/44663 which IMO replaces this issue, so I'm going to close this, but note that it will be implemented!


iOS: UIGraphicsImageRenderer can't render FlutterView layer

Steps to reproduce

Run Flutter application on iOS simulator/device
Get reference to layer of most top FlutterView
Create UIGraphicsImageRenderer based on that layer
Use render to create UIImage.

Expected results

UIImage has the proper size and reflects the FlutterView layer
No Xcode warning about CGBitmapContextGetHeight

Actual results

Xcode prints a warning message

CGBitmapContextGetHeight: invalid context 0x600003704e40. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable.

Reason: https://api.flutter.dev/ios-embedder/_flutter_view_8mm_source.html line 183

UIGraphicsImageRenderer returns empty UIImage instance

NB! The same mechanism works well with regular UIView.
Code sample
Code sample
import UIKit
import Flutter

@UIApplicationMain
@objc class AppDelegate: FlutterAppDelegate {
    override func application(
        _ application: UIApplication,
        didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?
    ) -> Bool {

        GeneratedPluginRegistrant.register(with: self)

        // Waits for layouting UI.
        DispatchQueue.main.asyncAfter(deadline: .now() + .seconds(3)) {
            if let layer = UIApplication.shared.windows.first?.rootViewController?.view.layer {
                let renderer = UIGraphicsImageRenderer(size: layer.frame.size)
                let image = renderer.image { context in
                    layer.render(in: context.cgContext)
                }
                print("Empty/black image: ", image)
            }
        }

        return super.application(application, didFinishLaunchingWithOptions: launchOptions)
    }
}

ios_issue.zip

Screenshots or Video

Screenshots / Video demonstration

Logs
Logs
Flutter output
Launching lib/main.dart on iPhone 15 in debug mode...
main.dart:1
Xcode build done.                                           29.8s
[VERBOSE-2:FlutterDarwinContextMetalImpeller.mm(35)] Using the Impeller rendering backend.
Connecting to VM Service at ws://<IP_ADDRESS>:53066/flsCttNRM44=/ws

Xcode
[VERBOSE-2:FlutterDarwinContextMetalImpeller.mm(35)] Using the Impeller rendering backend.
flutter: The Dart VM service is listening on http://<IP_ADDRESS>:52515/6x-427nmrM0=/
CGBitmapContextGetHeight: invalid context 0x600003774240. If you want to see the backtrace, please set CG_CONTEXT_SHOW_BACKTRACE environmental variable.
Empty/black image:  <UIImage:0x600003012a30 anonymous {393, 852} renderingMode=automatic(original)>

Flutter Doctor output
Doctor output
[✓] Flutter (Channel stable, 3.10.5, on macOS 14.3.1 23D60 darwin-x64, locale en-GB)
    • Flutter version 3.10.5 on channel stable at /Users/%USERNAME%/Developer/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 796c8ef792 (8 months ago), 2023-06-13 15:51:02 -0700
    • Engine revision 45f6e00911
    • Dart version 3.0.5
    • DevTools version 2.23.1

[!] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1)
    • Android SDK at /Users/%USERNAME%/Library/Android/sdk
    • Platform android-33, build-tools 32.1.0-rc1
    • ANDROID_HOME = /Users/%USERNAME%/Library/Android/sdk
    • ANDROID_SDK_ROOT = /Users/%USERNAME%/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    ✗ Android license status unknown.
      Run `flutter doctor --android-licenses` to accept the SDK licenses.
      See https://flutter.dev/docs/get-started/install/macos#android-setup for more details.

[✓] Xcode - develop for iOS and macOS (Xcode 15.2)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15C500b
    • CocoaPods version 1.15.2

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.86.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.82.0

[✓] Connected device (5 available)
    • Yurii’s iPhone (mobile)  • 00008020-001C35EE1A52002E            • ios            • iOS 16.7.2 20H115
    • iPhone 12 (RED) (mobile) • 00008101-001168461E10001E            • ios            • iOS 17.2.1 21C66
    • iPhone 15 (mobile)       • A412B6FF-467D-49B5-A98B-19C31CA29A63 • ios            •
      com.apple.CoreSimulator.SimRuntime.iOS-17-2 (simulator)
    • macOS (desktop)          • macos                                • darwin-x64     • macOS 14.3.1 23D60 darwin-x64
    • Chrome (web)             • chrome                               • web-javascript • Google Chrome 121.0.6167.160

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

Thanks for the report @dukhovnyi
I tried running the app you shared, but is giving me below error upon running:
/bin/sh: /Users/ydukhovnyi/Developer/flutter/packages/flutter_tools/bin/xcode_backend.sh: No such file or directory
Command PhaseScriptExecution failed with a nonzero exit code

I also see that you are on older version of stable. Can you upgrade to latest stable and confirm if the behavior still persist or not ?

Thank you @darshankawar for so quick reply.
I've updated Flutter to the 3.16.9 version (see details below) and checked once again.
Now when I try to capture the Flutter iOS layer I get the crash.
I've updated Flutter and Xcode projects to make them simpler and easier to reproduce. Also, I attached crash reports.
Sample project
Crash report

flutter doctor -v
[✓] Flutter (Channel stable, 3.16.9, on macOS 14.3.1 23D60 darwin-x64, locale en-GB)
    • Flutter version 3.16.9 on channel stable at /Users/ydukhovnyi/Developer/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 41456452f2 (3 weeks ago), 2024-01-25 10:06:23 -0800
    • Engine revision f40e976bed
    • Dart version 3.2.6
    • DevTools version 2.28.5

[✓] Android toolchain - develop for Android devices (Android SDK version 32.1.0-rc1)
    • Android SDK at /Users/ydukhovnyi/Library/Android/sdk
    • Platform android-33, build-tools 32.1.0-rc1
    • ANDROID_HOME = /Users/ydukhovnyi/Library/Android/sdk
    • ANDROID_SDK_ROOT = /Users/ydukhovnyi/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.2)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15C500b
    • CocoaPods version 1.15.0

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.86.1)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.82.0

[✓] Connected device (4 available)
    • iPhone 12 (RED) (mobile) • 00008101-001168461E10001E            • ios            • iOS 17.2.1 21C66
    • iPhone 15 (mobile)       • A412B6FF-467D-49B5-A98B-19C31CA29A63 • ios            •
      com.apple.CoreSimulator.SimRuntime.iOS-17-2 (simulator)
    • macOS (desktop)          • macos                                • darwin-x64     • macOS 14.3.1 23D60 darwin-x64
    • Chrome (web)             • chrome                               • web-javascript • Google Chrome 121.0.6167.184

[✓] Network resources
    • All expected network resources are available.

• No issues found!

Thanks for the update. Checked this on Flutter stable and master channels:
On stable channel, I see app crashed with below trimmed head log (looks similar to your crash report). On master channel,  app has not crashed but an error has been caught on _invokeIosMethod method.

Trimmed head log when crash occurs (stable channel)
Thread 0::  Dispatch queue: com.apple.main-thread
0   libsystem_kernel.dylib        	       0x109d4560e __psynch_cvwait + 10
1   libsystem_pthread.dylib       	       0x109e9276b _pthread_cond_wait + 1211
2   Flutter                       	       0x111d8e522 std::_LIBCPP_ABI_NAMESPACE::condition_variable::wait(std::_LIBCPP_ABI_NAMESPACE::unique_lock<std::_LIBCPP_ABI_NAMESPACE::mutex>&) + 18
3   Flutter                       	       0x11207bee4 fml::AutoResetWaitableEvent::Wait() + 58
4   Flutter                       	       0x1121ce423 flutter::Shell::Screenshot(flutter::Rasterizer::ScreenshotType, bool) + 345
5   Flutter                       	       0x111d4fa9d -[FlutterEngine takeScreenshot:asBase64Encoded:] + 23
6   Flutter                       	       0x111d631e4 -[FlutterView drawLayer:inContext:] + 128
7   QuartzCore                    	       0x10b750376 -[CALayer _renderForegroundInContext:] + 1318
8   QuartzCore                    	       0x10b74f686 -[CALayer renderInContext:] + 1748
9   QuartzCore                    	       0x10b751477 -[CALayer _renderSublayersInContext:] + 466
10  QuartzCore                    	       0x10b74f696 -[CALayer renderInContext:] + 1764
11  QuartzCore                    	       0x10b751477 -[CALayer _renderSublayersInContext:] + 466
12  QuartzCore                    	       0x10b74f696 -[CALayer renderInContext:] + 1764
13  QuartzCore                    	       0x10b751477 -[CALayer _renderSublayersInContext:] + 466
14  QuartzCore                    	       0x10b74f696 -[CALayer renderInContext:] + 1764
15  Runner                        	       0x10619f232 closure #1 in AppDelegate.captureLayerWithImageRenderer(layer:) + 114 (AppDelegate.swift:74)
16  Runner                        	       0x10619f2ac thunk for @callee_guaranteed (@guaranteed UIGraphicsImageRendererContext) -> () + 12
17  Runner                        	       0x10619f335 thunk for @escaping @callee_guaranteed (@guaranteed UIGraphicsImageRendererContext) -> () + 53
18  UIKitCore                     	       0x11fda4c29 -[UIGraphicsRenderer runDrawingActions:completionActions:format:error:] + 379
19  UIKitCore                     	       0x11fda4a82 -[UIGraphicsRenderer runDrawingActions:completionActions:error:] + 104
20  UIKitCore                     	       0x11fd9f883 -[UIGraphicsImageRenderer imageWithActions:] + 152
21  Runner                        	       0x10619f07a AppDelegate.captureLayerWithImageRenderer(layer:) + 394 (AppDelegate.swift:73)
22  Runner                        	       0x10619e189 closure #1 in AppDelegate.application(_:didFinishLaunchingWithOptions:) + 1113 (AppDelegate.swift:33)
23  Runner                        	       0x10619ebdb thunk for @escaping @callee_guaranteed (@guaranteed FlutterMethodCall, @guaranteed @escaping @callee_guaranteed (@in_guaranteed Any?) -> ()) -> () + 123
24  Flutter                       	       0x1123c42eb __45-[FlutterMethodChannel setMethodCallHandler:]_block_invoke + 168
25  Flutter                       	       0x111d7a472 invocation function for block in flutter::PlatformMessageHandlerIos::HandlePlatformMessage(std::_LIBCPP_ABI_NAMESPACE::unique_ptr<flutter::PlatformMessage, std::_LIBCPP_ABI_NAMESPACE::default_delete<flutter::PlatformMessage>>) + 94
26  libdispatch.dylib             	       0x109bf7a90 _dispatch_call_block_and_release + 12
27  libdispatch.dylib             	       0x109bf8d3a _dispatch_client_callout + 8
28  libdispatch.dylib             	       0x109c07ac0 _dispatch_main_queue_drain + 1420
29  libdispatch.dylib             	       0x109c07526 _dispatch_main_queue_callback_4CF + 31
30  CoreFoundation                	       0x107932850 __CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 9
31  CoreFoundation                	       0x10792d18b __CFRunLoopRun + 2463
32  CoreFoundation                	       0x10792c409 CFRunLoopRunSpecific + 557
33  GraphicsServices              	       0x109f76187 GSEventRunModal + 137
34  UIKitCore                     	       0x12039d3a2 -[UIApplication _run] + 972
35  UIKitCore                     	       0x1203a1e10 UIApplicationMain + 123
36  Runner                        	       0x10619f5ff main + 63 (AppDelegate.swift:5)
37  dyld_sim                      	       0x1066023ee start_sim + 10
38  dyld                          	       0x1077a33a6 start + 1942

Error caught on master channel
Layer has not been captured. Error="type 'String' is not a subtype of type 'int?' in type cast"

flutter doctor -v (stable and master)
[✓] Flutter (Channel stable, 3.16.9, on macOS 14.1 23B74 darwin-x64, locale en-VN)
    • Flutter version 3.16.9 on channel stable at /Users/huynq/Documents/GitHub/flutter
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 41456452f2 (14 hours ago), 2024-01-25 10:06:23 -0800
    • Engine revision f40e976bed
    • Dart version 3.2.6
    • DevTools version 2.28.5

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.14.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.1)
    • Android Studio at /Applications/Android Studio Hedgehog.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • android-studio-dir = /Applications/Android Studio.app/
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.85.2)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.80.0

[✓] Connected device (4 available)
    • RMX2001 (mobile) • EUYTFEUSQSRGDA6D                         • android-arm64  • Android 11 (API 30)
    • iPhone (mobile)  • d9a94afe2b649fef56ba0bfeb052f0f2a7dae95e • ios            • iOS 15.8 19H370
    • macOS (desktop)  • macos                                    • darwin-x64     • macOS 14.1 23B74 darwin-x64
    • Chrome (web)     • chrome                                   • web-javascript • Google Chrome 120.0.6099.234

[✓] Network resources
    • All expected network resources are available.

• No issues found!

[!] Flutter (Channel master, 3.20.0-7.0.pre.58, on macOS 14.1 23B74 darwin-x64, locale en-VN)
    • Flutter version 3.20.0-7.0.pre.58 on channel master at /Users/huynq/Documents/GitHub/flutter_master
    ! Warning: `flutter` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/flutter, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    ! Warning: `dart` on your path resolves to /Users/huynq/Documents/GitHub/flutter/bin/dart, which is not inside your current Flutter SDK checkout at /Users/huynq/Documents/GitHub/flutter_master. Consider adding /Users/huynq/Documents/GitHub/flutter_master/bin to the front of your path.
    • Upstream repository https://github.com/flutter/flutter.git
    • Framework revision 0fac13b443 (5 hours ago), 2024-02-14 22:43:18 +0000
    • Engine revision 3af336bfb2
    • Dart version 3.4.0 (build 3.4.0-140.0.dev)
    • DevTools version 2.33.0-dev.6
    • If those were intentional, you can disregard the above warnings; however it is recommended to use "git" directly to perform update checks and upgrades.

[✓] Android toolchain - develop for Android devices (Android SDK version 34.0.0)
    • Android SDK at /Users/huynq/Library/Android/sdk
    • Platform android-34, build-tools 34.0.0
    • ANDROID_HOME = /Users/huynq/Library/Android/sdk
    • Java binary at: /Applications/Android Studio.app/Contents/jbr/Contents/Home/bin/java
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)
    • All Android licenses accepted.

[✓] Xcode - develop for iOS and macOS (Xcode 15.0.1)
    • Xcode at /Applications/Xcode.app/Contents/Developer
    • Build 15A507
    • CocoaPods version 1.14.3

[✓] Chrome - develop for the web
    • Chrome at /Applications/Google Chrome.app/Contents/MacOS/Google Chrome

[✓] Android Studio (version 2023.1)
    • Android Studio at /Applications/Android Studio Hedgehog.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • Java version OpenJDK Runtime Environment (build 17.0.7+0-17.0.7b1000.6-10550314)

[✓] Android Studio (version 2022.2)
    • Android Studio at /Applications/Android Studio.app/Contents
    • Flutter plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/9212-flutter
    • Dart plugin can be installed from:
      🔨 https://plugins.jetbrains.com/plugin/6351-dart
    • android-studio-dir = /Applications/Android Studio.app/
    • Java version OpenJDK Runtime Environment (build 17.0.6+0-17.0.6b802.4-9586694)

[✓] VS Code (version 1.86.0)
    • VS Code at /Applications/Visual Studio Code.app/Contents
    • Flutter extension version 3.82.0

[✓] Connected device (3 available)
    • iPad (mobile)   • 00008103-000A1464346A201E • ios            • iOS 17.2 21C62
    • macOS (desktop) • macos                     • darwin-x64     • macOS 14.1 23B74 darwin-x64
    • Chrome (web)    • chrome                    • web-javascript • Google Chrome 121.0.6167.160

[✓] Network resources
    • All expected network resources are available.

! Doctor found issues in 1 category.

This may be related/similar to https://github.com/flutter/flutter/issues/139733.

I tested with the master branch also and it looks like the crash doesn't happen there, however, the Xcode warning is still there and the captured layer is truncated.
I updated the sample project and added a view to have the possibility to preview the FlutterView layer that has been captured.
Thank you for helping in advance.
ios_issue 3.zip

Does it only happen on latest version of iOS? Can you try using this UIView API instead? https://developer.apple.com/documentation/uikit/uiview/1622589-drawviewhierarchyinrect

Does it only happen on latest version of iOS?

I also see the issue occurs on my physical device iPhone 7, iOS 15.8.

Does it only happen on latest version of iOS? Can you try using this UIView API instead? https://developer.apple.com/documentation/uikit/uiview/1622589-drawviewhierarchyinrect

@hellohuanlin drawviewinhierarchy API works and we can use the drawviewinhierarchy method temporarily. However, for our purposes, the window.layer works better since that method handles better presented views and alerts.

the window.layer works better since that method handles better presented views and alerts.

can you elaborate more?

We faced that if window rendering happens using UIWindow.layer we receive better representation including some presented views. In the case of drawviewinhierarchy we need to enumerate all views to get the top view. If the top view is alert or popup the image will have a black background instead of a layer placed above the alert.
Perhaps it is related to our product specific, however, the performance stuff is still valuable for us and we don't want (if possible) to enumerate all presented views to capture the top view.
Does it make sense?

If you would like, I can extend sample application to show you differences between these two approaches.

I've seen a similar issue somewhere else in the plugin, and suspect that this may be an iOS issue (Does it only happen to certain version of iOS 17?)
An idea is to try it out on native app and see the result, if anyone is interested.

@hellohuanlin

Does it only happen to certain version of iOS 17?

I tested the issue on iOS 16.7.2 today and it works the same way as on iOS 17.2.1. I used Flutter from master. The crash doesn't happen, layer captures but the size is not correct and the image is cut, and Xcode throws warning into console.
Also, @huycozy mentioned the issue reproduces for his iOS 15.8
So, the affected versions are 15.8, 16.7.2, 17.2.1

An idea is to try it out on native app and see the result, if anyone is interested.

I've created a new native Xcode project for iOS and implemented UI with the same three buttons as in the Flutter project. Each button does the same as in Flutter, so difference only in the view that is captured (in native - UIView, in Flutter - FlutterView).
The native project has no capturing issues, cutting images, and runtime errors like in Flutter.
I recorded the comparison video. In this video, you can see differences between capturing views form native and Flutter applications on the same device.
Also, I attached the sample project with native implementation, so it could be pretty easy to check how it works in native project.
https://github.com/flutter/flutter/assets/125041274/df84ef5f-3064-499b-9f65-81c729355c1f
ios_issue_native.zip

@hellohuanlin

Does it only happen to certain version of iOS 17?

I tested the issue on iOS 16.7.2 today and it works the same way as on iOS 17.2.1. I used Flutter from master. The crash doesn't happen, layer captures but the size is not correct and the image is cut, and Xcode throws warning into console.
Also, @huycozy mentioned the issue reproduces for his iOS 15.8
So, the affected versions are 15.8, 16.7.2, 17.2.1

An idea is to try it out on native app and see the result, if anyone is interested.

I've created a new native Xcode project for iOS and implemented UI with the same three buttons as in the Flutter project. Each button does the same as in Flutter, so difference only in the view that is captured (in native - UIView, in Flutter - FlutterView).
The native project has no capturing issues, cutting images, and runtime errors like in Flutter.
I recorded the comparison video. In this video, you can see differences between capturing views form native and Flutter applications on the same device.
Also, I attached the sample project with native implementation, so it could be pretty easy to check how it works in native project.
https://github.com/flutter/flutter/assets/125041274/df84ef5f-3064-499b-9f65-81c729355c1f
ios_issue_native.zip


Abdiaziz.json

Masha allah

Masha Allah Brother shaqa fican aa qabatay Kaliya samayso File ku qor Magacaaga.json kadib ku qor tusalaha ku dhexjira example.jso thanks brother

Thanks
On Thu, 21 Jul 2022, 10:44 Abdorizak Abdalla, @.***>
wrote:

Masha Allah Brother shaqa fican aa qabatay Kaliya samayso File ku qor
Magacaaga.json kadib ku qor tusalaha ku dhexjira example.jso thanks brother
—
Reply to this email directly, view it on GitHub
https://github.com/abdorizak/Learn_Git_and_GitHub/pull/3#issuecomment-1191155848,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AUGCS2AIPF4GEK3IVG3D5TTVVD5XNANCNFSM54GSR3MQ
.
You are receiving this because you authored the thread.Message ID:
@.***>

dib usoo samey pull request Eng mahadsanid.


Fail2ban Traccar Filter

Is it possible to create a Fail2ban filter for Traccar with the open Port in iptables?
I opend Port 5055 for android device on the server in iptables.
anybody who secured the server by this way?

Fail2ban uses regular expressions for filtering, so it should be possible to configure it with Traccar. I haven't tried it though.
If someone has experience or working config, it would be great if he could share it with community.

Nobody who knows how to scan traccar with fail2ban an integrate with iptables to make it more secure ?

I'm also looking for it . Thanks.

I can try to make one, but dont think it is a good idea, because most mobile operators NAT a lot of devices behind couple of IP addresses, so you can block your own devices too. In my logs there are many devices that come from same ip address.

Okay, that sounds strange.. I thought about a filter looking for waring if unknown devices want to sent data to server. then block the ip adress after 3 or more times. And maybe also scanning other stuff doing bad things to the open Port. (using devices over Port 5055)

@tananaev Can we add remote ip address to "Unknown device" line easy, to parse it easier when we have a lot of traffic on server?

@nelim, I have just added IP address to the log messages (c6692703c8099577cb86c3eace5d8d1bc11f212d).

@dschense
You can append that in jail.conf
[traccar]
enabled = true
port	= 5002,5055
filter	= traccard
banaction = iptables-multiport
logpath  = /opt/traccar/logs/tracker-server.log
maxretry = 3
and copy https://nelim.han.bg/pro/traccard.conf on your fail2ban/filter.d/ directory
You must keep in mind 2 imoprtant things

Traccar show Unknown device, IF and ONLY unknown device connect on exactly protocol port.
for example, if osmand connect on port 5055 and is not in database, it report unknown device and ip, but if such request is send on port 5002, it just make connection and does not report anything..
this means that you cant ban scanning stuff that is doing bad things.
as i said before, be aware that you can ban whole mobile operators if some GPRS devices that are not added to your devices try to connect, which can affect your own devices.

Good luck :)

Wow, that's great, I will play with your solution and report back ;-)
Thanks so far!

@nelim Thanks you for great work
How to block IP for some time ? let's say if a user makes 3 or more hits within 1-3 seconds , and block that IP for 5 minutes

@chathudan
You are looking for common fail2ban options
bantime = 300 (5 minutes ban)
maxretry = 3 (3 fail hits)
findtime = 300 (5 minutes) - this is time in logs between maxretry, if 3rd retry is in 301 sec it starts new count.


How should I implement a keep-alive ping mechanism for an external component

I have written a full functional framework with a browser client using pure JavaScript and Strophe.js library to connect through BOSH to a OpenFire XMPP server talking to an "external component" written in NodeJS with junction.
Everything is working OK but the component is dissapearing from the OpenFire external components list (in admin web page) after a timeout of 10 minutes or so of inactivity. Probably this is a normal behaviour but:

is there a chance to raise this time limit?
how should I implement something like a keep-alive ping mechanism to make the component persistent for a very long time?

Thanks,
Constantin Teodorescu

https://github.com/strophe/strophejs/pull/119

strophe/strophejs#119

this don't work.


Add native support for TOML syntax highlighting

TOML is increasingly used in the Python community but boy does it look ugly in native VSCode!
This issue was raised a few years back and closed soon after by the original poster due to being told there is already support via plugins; that said, there is always inherent value in syntax highlighting being a native feature to an IDE without relying on third party code bases.
For that reason I'd like to re-raise the idea!

Whoops, seeing this has been covered time and time again: https://github.com/microsoft/vscode/commit/f2f8b7cb08d80184d1df76234b236760ae9a72f5
Nevermind 😅


Image not change

While pick image from gallery and set it to blurimageview . first time set correctly..
but second time pick image then set it to blurimageview .. at that previously image not change with newly selected image

Hi @bhavinsetubridge , I'll check this report and give you a feedback!

error: duplicate value for resource 'attr/radius' with config ''.
Message{kind=ERROR, text=error: duplicate value for resource 'attr/radius' with config ''., sources=[/root/.gradle/caches/transforms-1/files-1.1/appcompat-v7-27.1.1.aar/0ae86e86240d032cb52109724efdc4c3/res/values/values.xml:251:5-69], original message=, tool name=Optional.of(AAPT)}

For me it doesn't work in Recycler View. Nothing is changing.

Till Date this is not working . Any way thanks for making this Frame Work :)

Till Date issue is remaining ^_^  ! LOL


Home Page: Design & Implementation

Goal:
Design and implement the frontend of the home page using HTML, CSS, Javascript, & Django templating language (DTL).
Primary Stack:

HTML
CSS
JS
Django Templating Language (DTL)

Acceptance Criteria:
Following requirements need to be met before merging the changes into main.

General notes:

Create a base.html file under templates/app directory. All your HTML and DTL code would be in this directory.
All the static files (JS, CSS, and libraries) should go in the static directory. Appropriate sub-directories have been created so use them accordingly to place your files.
Please DO NOT hard-code the path to your static files while importing it to the template (HTML) files. If you hard-code it, might work in dev, but it will break during deployment in production. You need to use DTL url tags while importing files. Details can be found at Django templates documentation. More details will be added under resources.
This ticket won't require any interaction with the database or the backend. You would only need to add your changes to the templates and the static directory. Therefore, this is a good first issue.
The implemented UI should preferably be mobile-responsive. Therefore, please test it with different dimensions on your browser. Chrome provides dev tools to view your website on different mobile devices. Please find the details here.
Designing the front-end from scratch can be intimidating. It's okay to use code snippets and templates. If you plan to do so, please give credits to the original provider appropriately.

 Color scheme:

We haven't picked a color scheme for the project yet.
Therefore, the person working on this issue will get to decide the color scheme.
Try to get it approved by one of the e-board members before you start developing it.

Navbar:

Feel free to be creative with the design.
However, it should include the following sections:

Logo (Routes to the home page when clicked)
About (Route it to the specific section on the home page)
Meetings (Route it to the home page for now)
Guest Speakers (Route it to the home page for now)
Events (Route it to the home page for now)
FAQ (Route it to the specific section on the home page)
E-Board (Route it to the specific section on the home page)
Contact (Route it to the specific section on the home page)

Navbar should be mobile responsive. Should convert to hamburger on smaller devices.
Tip: Using the bootstrap navbar would make life a lot easier. Find the docs here.

Notifications Space:

Again, feel free to design it as per your convenience but using bootstrap alerts would make life easier. Find the docs here.
The goal of this space is to display text notifications for any major upcoming events, meetings, etc.
It should be placed somewhere near the navbar and will be hidden unless there's a new notification that needs to be displayed.
Notification will be added from the backend. It will be taken care of later. So feel free to hard-code it now. Here's an example.

Home Header:

The section which the user lands on when visiting the website. You can be as creative as possible on this one.
Some good UI ideas are to include carousels, graphics, or text about the club goals. Here's an example.

About:

Details about the club purpose and history.
Once designed and implemented, point the navbar section to this.

FAQ:

Section to include frequently asked questions about the club.
Don't need to write the actual questions and answers. Can hard-code it for now and edited later. Here's an example.
Once designed and implemented, point the navbar section to this.

E-board:

Section to include the details and contact of the e-board members.
Feel free to be creative but bootstrap cards can make life easier. View the documentation here.
Once designed and implemented, point the navbar section to this.

Contact:

Section should include general contact information about the site administrators.
Find an example here.
This section should be followed by the copyrights footer for appropriate accreditation of the resources.
Once designed and implemented, point the navbar section to this.

Resources:
Following are the resources that will help you get through the ticket.

Frontend Design & Implementation:

Bootstrapmade (Free templates available with appropriate credits)
Django template language
Bootstrap Docs
HTML Tutorial
JavaScript Tutorial
CSS Tutorial

i do not know django but i will use html, css and javascript


Readme Typo

There are extra commas in xml to json section of the readme:
convert: {
options: {
explicitArray: false, <-------------------HERE
},
xml2json: {
files: [
{
expand: true,
cwd: 'test/fixtures/',
src: ['**/*.xml'],
dest: 'tmp/result/',
ext: '.json'
}
]
}, <-------------HERE
}

is this a duplicate of #40?

Huh... not sure how this happened. Yes, its a dupe, but with more info (note, 2 commas called out). My bad, I meant to edit and somehow created a new ticket. Sorry... haha

no prob!


Add pre-commit action for REUSE compliance check.

Change proposed in this Pull Request
This PR adds a pre-commit action for REUSE compliance check.
Motivation and Context
Easier, automated checks for REUSE compliance.
How Has This Been Tested?
Locally.
Type of change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist

[x] I tested my contribution locally and it seems to work fine.
[ ] n/a I locally ran pytest inside the repository and no unexpected problems came up.
[ ] n/a I have adjusted the docstrings in the code appropriately.
[ ] n/a I have documented the effects of my code changes in the documentation doc/.
[ ] n/a I have added newly introduced dependencies to environment.yaml file.
[ ] n/a I have added a note to release notes doc/release_notes.rst.
[ ] I have used pre-commit run --all to lint/format/check my contribution

Ready for review. Please review and merge if everything is in order.


[IOTDB-2651] Fix write performance deteriorates severely

see IOTDB-2651

Coverage increased (+0.04%) to 67.734% when pulling 0ba2167bbd8728778b37b839cb4ee144b282c972 on THUMarkLau:IOTDB-2651 into 107cdc6d2f6a8a6417671b5ebcf92acbc907c95a on apache:master.


Dependency conflicts - halstack-react 9+ /  React 18 / NPM 9

Describe the bug
When installing a project that includes "@dxc-technology/halstack-react": "^9.1.0" and "react": "^18.2.0" as dependencies, you get several conflicts due to<EMAIL_ADDRESS>npm WARN While resolving<EMAIL_ADDRESS>npm WARN Found<EMAIL_ADDRESS>npm WARN node_modules/react-dom
npm WARN   peer<EMAIL_ADDRESS>|| ^17.0" from<EMAIL_ADDRESS>npm WARN   node_modules/@diaas/assure-platform-react-tools/node_modules/@radix-ui/react-popover/node_modules/@radix-ui/react-portal
npm WARN<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm WARN     node_modules/@diaas/assure-platform-react-tools/node_modules/@radix-ui/react-popover
npm WARN
npm WARN Could not resolve dependency:
npm WARN peer<EMAIL_ADDRESS>|| ^17.0" from<EMAIL_ADDRESS>npm WARN node_modules/@dxc-technology/halstack-react/node_modules/@radix-ui/react-popover
npm WARN<EMAIL_ADDRESS>from<EMAIL_ADDRESS>npm WARN   node_modules/@dxc-technology/halstack-react
npm WARN
npm WARN Conflicting peer dependency<EMAIL_ADDRESS>npm WARN node_modules/react-dom
npm WARN   peer<EMAIL_ADDRESS>|| ^17.0" from<EMAIL_ADDRESS>npm WARN   node_modules/@dxc-technology/halstack-react/node_modules/@radix-ui/react-popover
npm WARN<EMAIL_ADDRESS>from<EMAIL_ADDRESS>
It seems that<EMAIL_ADDRESS>is pinned in Halstack-react
Taking a look at that popover version, it seems that it's not React 18 compatible:
"peerDependencies": {
    "react": "^16.8 || ^17.0",
    "react-dom": "^16.8 || ^17.0"
  },

And Halstack-react requires React 18:
"peerDependencies": {
    "react": "^18.x",
    "react-dom": "^18.x",
    "styled-components": "^5.0.1"
  },

To Reproduce

create new npm application. (npm init)
Add de following dependencies

"dependencies": {
    "@dxc-technology/halstack-react": "^9.1.0",
    "react": "^18.2.0"
  }

install (npm install)

Expected behaviour
No conflicts when using halstack-react >=9 and react 18.
Screenshots
If applicable, add screenshots to help explain your problem.
Additional context
Taking a look at the possible solutions:

Force npm to resolve a different version in package.json:

"overrides": {
    "@radix-ui/react-popover": "0.1.7-rc.47"
  },

There is no final 0.1.7 release, so I tried with the last candidate version available. I tested it with CSAM Release Service UI and CSAM Environment Service UI with no issues during test executions or manual tests (at least for now... 😄).

Use "--legacy-peer-deps"

It's my second option, because this parameter will affect to the whole amount of dependencies and I want to use that functionality from npm 7+.
Add labels
Add any applicable label like the concerned components or the target version of the Design System where the bug has been found.

Hi @fredofm,
First of all, thanks for the feedback, and sorry for the late response. We will study the problem and try to solve it in the coming sprints.


9.0 merge 0709489

@yelizariev can you please answer the questions I asked before you go home today.


when use v-model with Array prop, update prop unexpected by someway.

Version
2.5.13
Reproduction link
https://jsfiddle.net/5uLrp7w6/
Steps to reproduce
step1. open
step2. click tab replied.
The detail I wrote in comments.
What is expected?
component update it's share data between parent component should be more strict.
I wish statement list[0].active = true should work.
What is actually happening?
statement list[0].active = true work unexpected, and it modified share data between it's parent component.

This is inherent to javascript nature: objects are passed by reference so all components end up modifying the same object.
BTW, you should declare active in the initial data.
I'm not sure why you are hardcoding values in your example but maybe this is what you want to do: https://jsfiddle.net/441w01qv/
Please, next time consider using the forum, the Discord server or StackOverflow for questions first. But feel free to come back and open an issue if it turns out to be a bug 🙂


thumbnail video

Hi,
I'd like to know after finished downloading video file then how to firstly display the thumbnail. This is because the videoview looks nothing and black before playing the video.

MediaMetadataRetrieve can do this

player not do like this because this is high cost, especially in a list, this is better do in server side and provide  a image as thumbnail to client apps

thanks


Tweak comment about debugging visually

There is a comment telling the user how to enable testing visually, but the setting in the comment actually makes the browser run in headless mode (which is the default) where there is no visual indication.

Thanks! This option could be exposed to the PureScript by having launch take an argument (headless: false) which makes it more obvious to someone who would be working on this in the future. Then the comment could be moved there where it is more obvious.
Up to you if you'd rather do that or just update the comment as is in this PR. Let me know what you'd like to do and I can merge!

I think that's a good idea - I can implement your suggestion now.

Thanks!


Auto generate tracers

finally got a working version with array1D/2D tracers.
When clicking generate at the top a new div pops up and you can create array 1d/2d tracers. The user can click inside each element in the matrix and edit it to any numeric value then press the generate JS and the code will appear in the tracer below. After this the user can copy and paste the code into the data.js file or the scratch pad.
what I like

I got to use similar code for 1d/2d array creation
a div overlay that just pops up for you can create these in any algorithm example and close it and it brings you back to the example

what I don't like

the visuals for the input fields and buttons
needs to look cleaner
createHTML() function in js/create/index.js (it works though)

todos:

add chart tracer
add graph tracer

I have tested this on Chrome, Safari, and Firefox, but it doesn't work on any of those.
It is unable to change columns and rows, create matrices, generate Javascript.
Could you check it again?

Interesting, its working for me on the website. Is there any console errors?

I don't see any errors in console.
On Thu, Jul 7, 2016, 1:55 AM Kevin Nadro<EMAIL_ADDRESS>wrote:

Interesting, its working for me on the website. Is there any console
errors?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub
https://github.com/parkjs814/AlgorithmVisualizer/pull/203#issuecomment-230835890,
or mute the thread
https://github.com/notifications/unsubscribe/ABizLPBqHRjEyj-g-bo2X6VL1G8EGy5jks5qS94RgaJpZM4JEuKd
.

Since you merged it to master its up on the site, I don't see any issues with it. I have tried on my computer and several other and it works fine, I have been testing in Chrome. Maybe some screen shots or video of the issues you are having?


Links to open a file are not generated

Please see attached PDF.
160202-2.pdf
in the bookmarks, the "go to another file" bookmark works in acrobat reader . but in pdf.js bookmark list (in sidebar),  there is no link generated in the anchor tag. when viewed in dev console. it is just
Go to another file

When opening an issue you need to provide all of the information requested in https://github.com/mozilla/pdf.js/blob/master/.github/ISSUE_TEMPLATE.md, otherwise the issue will be closed as INCOMPLETE/INVALID. (You've already been asked, on multiple previous occasions, to actually follow these instructions; so please just provide all information upfront to save everyone's time.)
Among the required information is clear and concise details under the "Steps to reproduce the problem:" heading, since there's no "go to another file" string anywhere to be found in the PDF file.

hi @snuffle its not the string in the pdf but the label of the bookmark in the bookmarks list.
it seems the html code got formatted into a real link instead.

I don't think it's fair to expect anyone to provide assistance if you cannot be bothered to actually read and follow explicit instructions, as outlined above.

ill recreate thanks


Imu/odometry orientation wrong using sbg/quat output on ENU

Hi,
During tests, I notice an issue with the orientation of the output odometry when you define the parameters  log_ekf_quat
I end up using only log_ekf_euler for the good orientation, using  the other set an offset of 90°.
Is it an issue with the direct use of the sbg_quat message in ENU convention ?
Regards

Hello,
Do you have any update on this issue ? I am observing the same behavior.

It should have been fixed with the latest rework around NED/ENU convention.
https://github.com/SBG-Systems/sbg_ros2_driver/pull/16


docker 1.7 not starting:  [graphdriver] prior storage driver "aufs" failed

Since the upgrade to version 1.7 docker does not start anymore at boot.
The error message in /var/log/upstart/docker.log is
/var/run/docker.sock is up
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
ERRO[0000] [graphdriver] prior storage driver "aufs" failed: backing file system is unsupported for this graph driver
FATA[0000] Error starting daemon: error initializing graphdriver: backing file system is unsupported for this graph driver

Other system info:

os: ubuntu 14.04 LTS,

docker installed via
wget -q0- https://get.docker.com/ | sh

docker version docker -v:
Docker version 1.7.0, build 0baf609

Hi!
Please read this important information about creating issues.
If you are reporting a new issue, make sure that we do not have any duplicates already open. You can ensure this by searching the issue list for this repository. If there is a duplicate, please close your issue and add a comment to the existing issue instead.
If you suspect your issue is a bug, please edit your issue description to include the BUG REPORT INFORMATION shown below. If you fail to provide this information within 7 days, we cannot debug your issue and will close it. We will, however, reopen it if you later provide the information.
This is an automated, informational response.
Thank you.
For more information about reporting issues, see https://github.com/docker/docker/blob/master/CONTRIBUTING.md#reporting-other-issues

BUG REPORT INFORMATION
Use the commands below to provide key information from your environment:
docker version:
docker info:
uname -a:
Provide additional environment details (AWS, VirtualBox, physical, etc.):
List the steps to reproduce the issue:
1.
2.
3.
Describe the results you received:
Describe the results you expected:
Provide additional info you think is important:
----------END REPORT ---------
#ENEEDMOREINFO

@andibachmann the "backing file system is unsupported for this graph driver" message indicates that you're trying to run docker (the aufs graph) on a filesystem that is known to cause problems. e.g. you cannot run aufs on top of another layered / copy-on-write filesystem (btrfs, for example).
In case of aufs, the (known) incompatible filesystems are "btrfs" and "aufs", which can be seen here: /daemon/graphdriver/aufs/aufs.go#L48

Providing more info:
$ docker version
Client version: 1.7.0
Client API version: 1.19
Go version (client): go1.4.2
Git commit (client): 0baf609
OS/Arch (client): linux/amd64

$ docker info
Cannot connect to the Docker daemon. Is 'docker -d' running on this host?

$ uname -a
Linux ls083 3.13.0-55-generic #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Procedures to start docker:
$ sudo service docker start

Error messages as in my initial comment.
$  sudo docker -d
INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
ERRO[0000] [graphdriver] prior storage driver "aufs" failed: backing file system is unsupported for this graph driver
FATA[0000] Error starting daemon: error initializing graphdriver: backing file system is unsupported for this graph driver

@andibachmann What file system is /var/lib/docker on? Can you provide the output of mount, please?

@thaJeztah : Ooops! I'm running on btrfs!
$ df -T
Filesystem     Type     1K-blocks     Used Available Use% Mounted on
/dev/sda1      btrfs    153600000 43613716 108387948  29% /
none           tmpfs            4        0         4   0% /sys/fs/cgroup
udev           devtmpfs   3924252       12   3924240   1% /dev
tmpfs          tmpfs       787044     1260    785784   1% /run
none           tmpfs         5120        0      5120   0% /run/lock
none           tmpfs      3935204<PHONE_NUMBER>   1% /run/shm
none           tmpfs       102400       28    102372   1% /run/user
/dev/sda1      btrfs    153600000 43613716 108387948  29% /home

I used to experiment with btrfs and forget about it, when I installed my current env half a year ago.
However, the previous version of docker where running smoothely, it's only after the upgrade
to version 1.7 (1 week ago).
Can I hope for relief, i.e. is this going to be supported?

@unclejack
$ mount
/dev/sda1 on / type btrfs (rw,subvol=@)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
none on /sys/fs/cgroup type tmpfs (rw)
none on /sys/fs/fuse/connections type fusectl (rw)
none on /sys/kernel/debug type debugfs (rw)
none on /sys/kernel/security type securityfs (rw)
udev on /dev type devtmpfs (rw,mode=0755)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=0620)
tmpfs on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755)
none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880)
none on /run/shm type tmpfs (rw,nosuid,nodev)
none on /run/user type tmpfs (rw,noexec,nosuid,nodev,size=104857600,mode=0755)
none on /sys/fs/pstore type pstore (rw)
cgroup on /sys/fs/cgroup/cpuset type cgroup (rw,relatime,cpuset)
cgroup on /sys/fs/cgroup/cpu type cgroup (rw,relatime,cpu)
/dev/sda1 on /home type btrfs (rw,subvol=@home)
systemd on /sys/fs/cgroup/systemd type cgroup (rw,noexec,nosuid,nodev,none,name=systemd)
gvfsd-fuse on /run/user/3190/gvfs type fuse.gvfsd-fuse (rw,nosuid,nodev,user=bachmann)

@andibachmann You've upgraded from a very old version of Docker to Docker 1.7. Your /var/lib/docker folder is on btrfs. aufs isn't meant to be used on btrfs. We've seen aufs+btrfs lead to data corruption and many other problems (interrupted builds, missing files, etc).
I'd suggest that you back up your important data and then wipe out /var/lib/docker. If you've used aufs on top of btrfs in the past, your Docker images might have missing or corrupted files.
The btrfs storage driver should be used on btrfs, not aufs.
Please keep in mind that problems have been reported against kernel 3.13 on Ubuntu 14.04. Should you really want to keep your images, keep using aufs or both, you can set up a separate partition at /var/lib/docker using ext4 and (optionally) migrate your existing images.

@unclejack Do I understand you correctly that my docker setup was mixing file system and storage drivers (and the misconfiguration resulted from an incorrect upgrade)? I.e., I just managed to start docker using
$ docker -d -s btrfs

Anyway, I'll throw away my current docker setup and containers (rm -rf /var/lib/docker).
But, before starting again, do I have to change my file system or will everything be OK?

@andibachmann Not quite.
Docker does not ever create btrfs partitions, so somewhere along the line /var/lib/docker was converted to a btrfs partition.

@cpuguy83 hmmm, but /var/lib/docker is just a ordinary folder in my / btrfs file system. I noted
that there are two subfolders aufs and btrfs accomapanied with repositories-aufs and repositories-btrfs. Looking at these json-files, I see that my 'latest' stuff is repositories-btrfs and
the 1 year old repositories-aufs contains my very first steps with docker.
On explanation is that last year when I started with docker I installed it using apt-get install docker. The version of this first docker installation was probably the usual 3 minor version numbers behind the official release. I played around with docker and then some more important tasks came by and docker slept until May this year.
With new spirits I restarted from scratch and installed the latest version of docker  (~1.6.2 ).
Everything work liked a charm (I and the new docker-bin didn't see the old images, but I didn't care anyway).
Then after the update to 1.7  docker seems to have changed a bit the backend storage driver setup and it got confused with old 'aufs' stuff.
Does that make sense?

@andibachmann ah yes, it does. In 1.7 we went from a straight priority list for the drivers to "check if there is already data for a driver and use that" if no specific graphdriver is selected in the daemon opts.
In the case where it's ambiguous (ie, a btrfs dir and an aufs dir), then it bails out.

OK. I just removed the subfolder aufs and the file repositories-aufs and then I issued a
service docker start

it works again!
Thank you!

@andibachmann
:+1:

:+1:

@andibachmann same problem here, your solution worked flawlessly. Thanks!

same problem and removing aufs was the trick like you said. Thanks guys!

It works for me and thanks very much.

same problem, same solution - thx!


Add a Gitter chat badge to README.md

nicoulaj/idea-markdown now has a Chat Room on Gitter
@nicoulaj has just created a chat room. You can visit it here: https://gitter.im/nicoulaj/idea-markdown.
This pull-request adds this badge to your README.md:
![Gitter](https://badges.gitter.im/Join Chat.svg)
Happy chatting.
PS: Click here if you would prefer not to receive automatic pull-requests from Gitter in future.

Notice: This plugin is no more maintained and it has been removed from Jetbrains plugins repository. There is a Markdown plugin officially supported by Jetbrains.


Add YAML support

Beside JSON also YAML files should be allowed as import data structure.
Here is a example code snippet:
from llm_prompting_gen.models.prompt_engineering import PromptEngineeringMessages
pe_msgs = PromptEngineeringMessages.from_yaml("test.yaml")

Solved


loading spinner

closes #208

generating differences is sadly not cancelable, job.cancel does not work.
parentJob lauch generation and then parentjob.cancel also does not work

What do we do with this then? @a-miscellaneous @AlperK61

What do we do with this then? @a-miscellaneous @AlperK61

next sprint, conflicts left

We have to make the difference generation cooperative for cancelling. Then, job.cancel() will work. I'll look into that now

After doing my research, it is pretty clear, that we can only cancel the job by injecting some kind of suspend function into the Algorithm.run() or some check if the job is still wanted. That would mean needing to refactor lib2 quite a bit so that it is cancel-aware... Unfortunately, the builtin Threat.yield() does not work as kotlinx.coroutines.yield and thus, lib2 must include kotlinx somehow.
Or... We redefine the algorithm to run in steps, like a ML training. Then, we could check if the job was cancelled between each step.
Some links I checked:
https://stackoverflow.com/questions/69097765/how-to-stop-or-cancel-a-kotlin-coroutine-stop-currently-running-code-block-inst
https://stackoverflow.com/questions/74065990/properly-cancelling-kotlin-coroutine-job

Rebased onto main and added singleton to cancel running algorithm instance.


Modified signature for returning the file instance

Heroku read-only policy needs this modification. I intended to use this brilliant API, so for displaying the image, I return the instance of the file, convert to base64 and send to my client in Angular 2.
Used on: https://github.com/albertjimenez/cvrptenis

Thanks a lot.


convert parameter set value to single precision floating point numbe…

…r (the type used by low level mavlink messages) before sending/comparing it
This fixes bougus "timeout setting parameter x to y" messages when the passed double value and it's single representation differ

great catch thanks!


Update time

Hi. Once again, thank you for your good work.
If I may, I would suggest you to add a 'Last update time' to the main screen.
It may be usefull so that you know that the displayed info is or is not updated, for example, in case of sensor fail or battery fail.
Thank you

Hello and thanks again for your contribution
That would be a good idea, I need to test some different to display the last update time. I'm looking for something useful but not ugly when using the app :D

Update time would be needed for every sensor.  Perhaps just set a stale timer and gray out the  older values.

Actually, when the tyre is filled with color, that mean tyre's data was read less than 5 minutes ago, when the tyre is emptied (only borders are displayed) this mean the tyre's data is at least 5 minutes old.
Battery is also read, just like the last update time, I need to find a nice way to display an alert when the battery level is low


Fmovies url change

Source information
Fmovies
Source language
English
Source new URL
Fmovies24.to
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 all installed extensions.
[X] I have opened WebView and checked that the source URL is not updated yet.
[X] I will fill out all of the requested information in this form.

Duplicate of #3291


Add RuntimeFilterCache to cache early-arrival GRF and speculative and passthrougth GRF delivery in BE

What type of PR is this：

[ ] bug
[ ] feature
[ ] enhancement
[ ] others

Which issues of this PR fixes ：

Fixes #
Problem Summary(Required) ：

https://github.com/StarRocks/starrocks/issues/4832
implemenation of Broadcast HashJoin' GRF optimization in BE

add a RuntimeFilterCache to cache the early-arrival GRFs.
GRF generated by broadcast HashJoin is delivered in speculative, passthrough and parallel style.

may be we need add a memory tracker for RuntimeFilterWorker thread. because the RuntimeFilterWorkerEvent was generate by pipeline work thread but it was released in RuntimeFilterWorker thread. It may cause inaccurate memory statistics

run starrocks_be_unittest

Is it enough to process RuntimeFilterEvent for RuntimeFilterWorker? It seems if one filter hang or timeout, other Filters in the queue need to wait all the time.

it is only used in dev or debug environment.


Removed unused code in android detect.py and SCsub

Removed unused code in android detect.py and SCsub.
These became useless after support for NDK < r15 was dropped in https://github.com/godotengine/godot/pull/30967.

Thanks!

Cherry-picked for 3.2.2.


[stable/couchdb] StatefulSet won't deploy on k8s 1.16

Describe the bug
CouchDB StatefulSet cannot be deployed on k8s 1.16 because of deprecated API use.
Version of Helm and Kubernetes:
1.16 K8s
Helm Version doesn't matter
Which chart:
incubator/couchdb
stable/couchdb
What happened:
When you try to deploy the chart on k8s 1.16, you get an error
Error: validation failed: unable to recognize "": no matches for kind "StatefulSet" in version "apps/v1beta2"
What you expected to happen:
It should deploy successfully.
How to reproduce it (as minimally and precisely as possible):
Try deploying the chart on k8s 1.16.
Minikube 1.4.0 can be used to reproduce this issue.
Anything else we need to know:
https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/

Moved and closed with https://github.com/apache/couchdb-helm/pull/2


unsatisfiable package requirements

I tried to add Pollen but package manager was not happy. Any idea what is wrong and how I can fix it?
(TestPollen) pkg> add https://github.com/lorenzoh/Pollen.jl
    Updating git-repo `https://github.com/lorenzoh/Pollen.jl`
   Resolving package versions...
ERROR: Unsatisfiable requirements detected for package ModuleInfo [3c3ff5e7]:
 ModuleInfo [3c3ff5e7] log:
 ├─ModuleInfo [3c3ff5e7] has no known versions!
 └─restricted to versions * by Pollen [c88717ad] — no versions left
   └─Pollen [c88717ad] log:
     ├─possible versions are: 0.1.0 or uninstalled
     └─Pollen [c88717ad] is fixed to version 0.1.0

Hey there!
Since Pollen.jl is not yet released and has some unreleased package dependencies, you’ll have to install these directly from their repositories for now:
using Pkg

Pkg.add([
    Pkg.PackageSpec(url="https://github.com/c42f/JuliaSyntax.jl"),
    Pkg.PackageSpec(url="https://github.com/lorenzoh/ModuleInfo.jl"),
    Pkg.PackageSpec(url="https://github.com/lorenzoh/Pollen.jl"),
])

See also [here|(https://lorenzoh.github.io/Pollen.jl/dev/i/?id=documents%2Fdocs%2Fhowto%2Finstall.md) in the docs. Hope this helps! :)


Navigating to steps based on a form's dropdown value

How to use the jumpToStep function on pressing the next button in stepzilla? Control needs to jump to a step based on a form's dropdown value.
The example has links for jumpToStep but I want to link it to the Next button in StepZilla. Is it possible?

You can use isValidated method to check dropdown value and use jumpToStep method inside it.


Use cvxsimulator to assess performance?

problem that cvxsimulator is price based rather than accepting returns

price = (1.0 + r).cumprod()


Lint

https://github.com/scratch-contributors/scratch-contributors.github.io/issues/5#issuecomment-851955411

https://github.com/marketplace/axe-linter?


The way of providing policy object as scope variable.

I have my own service around $http. This service set special headers, and authorisation before get policy. So I cannot provide url. So I made that you have another option when you can set policy with you got as an object with your own request.  The only problem for now is that the way you are dialing with attributes, is not 2 way and this parameter have to be resolved before assignment. That is ok for me because I use router ui and I can resolve things.
And I am sorry for readme file. My github client automatically stripped invisible symbols at the end of lines and formated it for github standards. basically I only added new line describing new feature.

See my minor comments, please fix and I'll be happy to merge. Thanks!

Done.

Thank you, awesome pull request.


fix error 403 during retrieval of traffic data for archived repos

Thanks :)
Was running into this issue as well, is fixed now


Add a Beamfits memo to describe the beam fits files

I just discovered (reading the WCS papers) that angles should always be in degrees for FITs files. I'm going to have to change some code to fix this, we're currently using radians throughout the beamfits code.

Ok, I've fixed the units to use degrees not radians per FITs standards. I also realized I was erroneously writing empty BASISVEC HDUs for power beams that didn't have basis vector arrays. I fixed that and updated the LaTeX to reflect the fact that that HDU is only required for E-field beams (but allowed for power beams).

@isullivan Ok, I think I've substantially improved the memo and code thanks to your comments. When you have time, can you give it another read and see if there are any more things to fix? I'll email you new versions of the files because there have been some improvements in this process.

Thanks @isullivan !


Using alpha4, SteamVR games such as In Death and Moss do not seem to recognize controllers as Oculus Touch.

For example:

Moss still prompts you to click on the right side of the touchpad to continue past seated notice, which is not possible with the controller mappings in alpha4.
In Death uses the trackpad click to select teleport arrow just like Vive, even though Oculus version maps teleport to the (right?) Touch grip button.  Also, the controller angle is off.

(I wonder if those games are checking the HMD information to detect Oculus Rift, and not the controller information to detect Oculus Touch)

Will check later tonight with alpha5

with alpha5, I still get stuck with Moss in the same place, for example;
there is no Touch controller input I have found that can dismiss that message

I can confirm it doesn't work either - my copy of moss is already past the above dialog, but when I bring up the menu it does show the left/right trackpad for forward/back - I hadn't even thought of it as detecting vive controllers but maybe that's what's happening since the Oculus touch controllers don't have trackpads.

OK so I was able to fix using SteamVR only:

in Steam list, right click entry for Moss and choose Properties
for Steam Input Per-Game Setting, change to Forced On
in SteamVR while VR is running, pick Devices / Configure Controller from the SteamVR window's app menu
set up the Moss mapping as described at https://steamcommunity.com/sharedfiles/filedetails/?id=1545634111#2763677 (see section 3 on Moss specifically)

So may be OK to close, unless/until ALVR gets native Oculus support working rather than SteamVR.


How to synchronize data to Jiaming Asia/China, which is two different accounts from Jiaming International

怎么把数据同步到佳明亚洲区/中国区，跟佳明国际区是两个账号

https://github.com/cyberjunky/home-assistant-garmin_connect/commit/36e5b7c6b8414358887b790fecabfcf4a3eac03c


Feature suggestion: Ability to assign keyboard focus to a callback.

This adds the ability to temporary gain keyboard focus, can be useful when you need to ignore other input callbacks, like if you are doing text input.
Example:
var inputFieldText = '';

game.input.keyboard.setFocus((e) => {
    if (e.type === 'keypress') {
        inputFieldText += String.fromCharCode(e.keyCode);
        console.log(inputFieldText);
    }
});

//.. Somewhere else
game.input.keyboard.clearFocus();

If you find the idea interesting I can refactor it ( its a bit messy atm ) and make a new PR.

I do quite like the idea, I'm just wary of calling it 'focus' as that has meaning already in browser-land, and it doesn't really do what 'focus' means there.

Yeah, good point. I'll give it some thought

Closing this since I deleted the repo and can't make changes to it. Will probably make a new one later today