[health] Download CSV via Gadgetbridge doesn't do anything

Affected hardware version
Bangle 2
Your firmware version
2v14
The bug
In Gadgetbridge, in the app list, when I click on the "save" icon, it shows the monthly data files on the watch with a choice "download CSV" and "delete".
Clicking on "Download CSV" gives a message "Please wait - downloading health info" but then nothing happens, and I can't find any downloaded CSV on my device. It does not show a directory selection dialogue or any indication where the file was downloaded to.
Expected behaviour: It should show a dialogue to select the location of the download and then actually create a CSV file there.
I don't know if this is an issue of the health app or the gadgetbridge app as I don't understand which app is actually responsible for this. This is on a Fairphone 4 with /e/OS (Android 11).

Please can you try downloading via https://banglejs.com/apps on a PC and see if it works there just in case? I just tried here on a PC and it works fine, but I believe I'm seeing this on Gadgetbridge too.

Clicking on "Download CSV" gives a message "Please wait - downloading health info" but then nothing happens

So the Please wait - downloading health info message disappears after?
I think the issue here might be that the WebView in Gadgetbridge may currently be set up such that it can't display any dialogs to choose files to read/write to.

Thanks. Yes, the "Please wait" message dissappears after a while and it's back to the list of months and the buttons "download" and "delete".
I tried it on PC now and it works as expected, so it's really only an issue in the Gadgetbridge app.

Ok, thanks. Just filed an issue on the Gadgetbridge port with https://github.com/gfwilliams/Gadgetbridge/issues/6

Closing this as the issue is on gadgetbridge

Thanks! Looks like I fixed this anyway https://codeberg.org/Freeyourgadget/Gadgetbridge/commit/c647c2647f1b14369edaf5d4597f14c369ec0510


add  discription for SEO

https://github.com/ashishpatel0720/maffick/issues/1
some thing like this

Meta information added by following commit,
742ca25094b08be2bc373853aa8bd1659c321573


JSON serialization of attributed C-sets

Serialize and deserialize attributed C-sets as JSON. Only the data in the tables field needs to be stored; the indices are redundant information.
To get started, we can assume that the data attributes are primitive JSON types, with perhaps special handling for Symbol vs String.

Yeah, it would be great to also convert the type of the ACSet into a https://json-schema.org/ so that you could get validation logic in other languages using these libraries https://json-schema.org/implementations.html

Serialization should be straightforward. For deserialization, I'd suggest the following procedure:

Add all parts of all types, without setting any subparts: add_parts!(acs, type, n).
Set all subparts for all parts: set_subparts!

This should ensure that all the indices are rebuilt correctly.

@mehalter this is working for AlgebraicPetri, is there anything else we need to do on this issue?

Implementation started and reviewed at PR #372.

I'll update that PR and get it ready for merging in the coming days! :D

Perfect, thanks!

Just finished up fixing the comments on the PR, should be ready for some more review and hopefully merging 😃

Resolved by #372. Thanks @mehalter!


When a nurse selects “Lab” for Hepatitis B test, the diagnosis for Hepatitis B and Referral activity don't appear. (and other scenarios)

Nutrition env

When a nurse selects “Point of Care” and the tests are positive for Hepatitis B and Malaria, two activities appear: Medical Distribution and Referral. I think only Referral should appear

When a nurse selects “Point of Care” and the tests are positive for Hepatitis B and Malaria, the diagnosis appears twice. And when Malaria is negative

Patient Akuzwe Gossy

When a nurse selects “Lab” for Hepatitis B test and the test is positive (and Malaria is negative - “Point of Care”), the diagnosis for Hepatitis B and Referral activity don't appear.

Patient Akuzwe Ketsia

When a nurse selects “Lab” for Hepatitis B and the test is positive (and Malaria is positive - “Point of Care”), the diagnosis for Hepatitis B and Referral activity don't appear. The Malaria diagnosis and Medical Distribution action are displayed before the lab test, and after the Medical Distribution action is completed, a Pause Encounter button appears.

There's no relation between Malarial and HepB. The confusion is from Logics Master file - seems someone has changed by mistake:

While it should be:

When a nurse selects “Point of Care” and the tests are positive for Hepatitis B and Malaria, two activities appear: Medical Distribution and Referral. I think only Referral should appear

No, both should appear.
Points 2, 3 and for are fixed at #1140.


Add ability to genereate multiple SDKs

Which issue this PR addresses:

Fixes https://msazure.visualstudio.com/AzureRedHatOpenShift/_workitems/edit/7508558/
What this PR does / why we need it:
Refactor SDK generation to support multiple SDK generation.

Test plan for issue:

Is there any documentation that needs to be updated for this PR?

/azp run e2e

@petrkotas  please address the comments :)

@mjudeikis was already on it and testing the inputs.
@m1kola I hope I answered your points.

@mjudeikis droped the last commit with generation of new sdk

@petrkotas
If we add this new generator, let's generate SDK too. But not change default API at the moment.
What will be needed to be fixed in subsequential PR is to make sure we dont change OLD api/SDK anymore with new changes we add.
TL:DR: make client and commit for this one before we merge

@petrkotas before reviews request can we make sure CI is passing. I think this is good but we can't merge

Sorry about that @mjudeikis my fault. I skimmed it and saw green, did not realized I am seeing only one. It will not happen again.

/azp run e2e


Rabby injected wallet not working using blocknative

Current Behavior
I should be able to connect using the Rabby wallet.
Expected Behavior
I should be able to connect using Rabby wallet.
Steps To Reproduce

Open https://oliveapp.finance/earn/vaults
Click Connect Wallet & Choose Rabby wallet option
It will not connect & don't through any error.

What package is effected by this issue?
@web3-onboard/core
Is this a build or a runtime issue?
Runtime
Package Version
2.8.8
Node Version
No response
What browsers are you seeing the problem on?
No response
Relevant log output
No Output in the console.

Anything else?
Versions
"@web3-onboard/injected-wallets": "^2.10.1",
"@web3-onboard/react": "^2.8.8",
"@web3-onboard/walletconnect": "^2.4.0",
Sanity Check

[X] If this is a build issue, I have included my build config. If this is a runtime issue, I have included reproduction steps and/or a Minimal, Reproducible Example.

@anuj0361 I will check this out and see if I can repro on my end, thanks for bring this to our attention!

Any updates on this

@anuj0361 @lm93547 Is this using Rabby through walletconnect or the injected package?

Using injected package @Adamj1232

@anuj0361 connect through our docs site and see if it works for you. It worked for me so I am assuming this is an issue with the olive app itself

@anuj0361 is this still an issue?

Resolved. Please close this issue. Got to know the name got changed from 'Rabby' to 'Rabby Wallet' in block-native library.


Make Vibration.vibrate compatible with TurboModules

Summary

This PR fixes a compatibility issue with the Vibration module and TurboModules.
The TurboModules spec doesn't allow nullable arguments of type Number, causing the following problem:

Changelog

[iOS] [Fixed] - Make Vibration library compatible with TurboModules.
Test Plan

Just submitted a PR to my own app to fix the issue here
The problem should be reproducible on RNTester due to this line: https://github.com/facebook/react-native/blob/91f139b94118fe8db29728ea8ad855fc4a13f743/RNTester/js/examples/Vibration/VibrationExample.js#L66  and should be working on this branch.

This is a great PR. Thanks for fixing this!

Ran into some issues landing this, which only surfaced internally due to TurboModules not being fully supported in open source yet.

Had to regenerate the native Java spec for the Vibration TurboModule, since the JS spec changed
In turn, this surfaced the following error, related to the generated method signatures having changed on Android:

stderr: ReactAndroid/src/main/java/com/facebook/react/modules/vibration/VibrationModule.java:20: error: com.facebook.react.modules.vibration.VibrationModule is not abstract and does not override abstract method vibrate(double) in com.facebook.fbreact.specs.NativeVibrationSpec
public class VibrationModule extends NativeVibrationSpec {
       ^
ReactAndroid/src/main/java/com/facebook/react/modules/vibration/VibrationModule.java:33: error: method does not override or implement a method from a supertype
  @Override
  ^

Do you think you can fix that up in your PR?

@hramos  Sure, np. I'll take a look some time this week.

@hramos Can you give it a try now?

Imported, but it ran into some issues. I'll look at this again sometime this week.

@hramos The same issue exists on 0.62.0. Is there any schedule when this pr could be merged? :)

Note: This error only exists on debug builds, it seems to work fine in release mode, for some reasons.. This PR fixes the issue.

This is still on my todo list, and the past month kind of threw things off. I'll try to take another look soon.

We're actively working on landing this change.

This is landing now. Thanks to @TheSavior for helping push this through.


Update_gdal_approx_eq

 GDAL-Release

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

66 of 72 (91.67%)  changed or added relevant lines in 10 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.03%) to 85.194%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

datatypes/src/primitives/bounding_box.rs
6
7
85.71%

datatypes/src/primitives/multi_polygon.rs
9
11
81.82%

datatypes/src/primitives/line.rs
0
3
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
0.03%

Covered Lines:
28027

Relevant Lines:
32898

💛  - Coveralls

bors merge


Add guidance about bumping the minimum required rustc version

As far as I know, this repository does not offer guidelines on when it is appropriate to bump a library crate's minimum required rustc version.  I've found that authors of widely used and foundational crates do not consider bumping the minimum rustc version to be a SemVer incompatible or breaking change (1, 2).  I think it would be appropriate to document what norms the Rust community expects on this issue, so that deviations from the norm can be fixed without having to re-litigate the meaning of SemVer.
My personal opinion on the matter is that bumping the required rustc version of a library is a backwards-incompatible SemVer change, since it requires applications depending on the library to follow suit.  This change can be every bit as painful for application authors as introducing a breaking API change (or more). The minimum rustc version is 'viral', and a breaking change by a foundational crates forces all other downstream crates to in turn bump their minimum version.  Cargo has good tools for introducing new features which may require a newer rustc version, while it has relatively poor support for resolving rustc version dependencies if the author of the library does not follow semantic versioning.  Thus, unless Cargo's version resolution begins taking into account required rustc versions, it's better for library authors to put new code requiring new rustc versions behind a feature flag.

I think it's fair and simple to assume any change to the minimum rustc version is a breaking change.
What's less clear is when that happens. If you happen to have a minimum version of 1.8.0 for your library then bundle in a few ?s with other internal refactorings then you've just bumped your minimum version, possibly without even realising it.
So I think a good recommendation is to pin a rustc version in CI, serde tracks 1.13.0, when you want to stabilise your library and any changes that break your build on that pinned version need an appropriately breaking version bump, or gymnastics with flags.

I am less of a hardliner on this, although I hear many people think I am wrong.
Serde tracks a Rust version in CI so that we don't accidentally raise the minimum, not because we never will.
Users should not have an expectation that they can selectively pin parts of their dependency graph while receiving updates to things that depend on those parts. In Serde's case, the serde and serde_derive crates are versioned in lockstep. Serde 1.0.5 and serde_derive 1.0.5 work together, and serde 1.0.10 and serde_derive 1.0.10 work together. There shouldn't be an expectation that you can pin serde to 1.0.5 and get to use serde_derive 1.0.10. Does that constitute a "breaking change" to serde_derive? Sure, technically.
Dependencies on the standard library or language should work analogously.

I'm not sure I agree that this needs to be treated as a breaking change. On one hand, you have the cost of forcing people to upgrade their rustc when cargo updateing. On the other, you have the cost of forcing the ecosystem to propagate new major versions throughout it.
Judging by the recent Rust community survey survey responses, ~95% of respondents were targeting 2 stable releases back or newer.
I am looking forward to picking up the bitflags crate's new use of associated consts. The various flags are way more discoverable attached to the relevant type rather than floating around the containing module. I can perform that upgrade in an API-compatible way with deprecated reexports, but if the rustc dependency bump is going to count as a breaking change, I'm just not going to do it for a year or so, probably. The pain of migrating the ecosystem forward across that breaking change is just too painful. rust-openssl 0.9 was released last November and people are still migrating off of the older releases. There are 1-2 issues opened per week against the rust-openssl repo that boil down to "upgrade to 0.9".

Usually I would expect bumping the minimum rustc version should not happen in bugfix release, e.g. 1.0.0 to 1.0.1, but certainly permissible when we have 1.0.0 to 1.1.0 as long as it is advertised as such.

I have some thoughts on this, but I think that at a minimum, we should be strongly recommending that folks include a specific version of Rust in their CI builds. This doesn't imply any particular semver policy, but does at least make bumping the minimum Rust version a conscious change. As someone who has tried to play the conservative side of this fence (semver bump for minimum rustc bump), I will say that having a pinned Rust version in a CI config makes the research task of determining the release policy of your dependencies much easier, and typically instantly clarifies the choices I actually have available to me.
I've been trying to straddle this line for a long time now myself, and it is very hard to do so. The hardest part about this problem is that there are significant reasons for choosing either side of this, and I think those reasons have already been highlighted in this thread. Another difficult aspect of this problem is that since there is no consensus on whether a minimum rustc version bump is actually a semver breaking change or not, you end up with an ecosystem where one needs to be aware of the release policy for each dependency of your code, because that policy is not necessarily communicated through version numbers. Even worse, this doesn't just apply to direct dependencies, but to all transitive dependencies too.
I'd like to collect a few of my experiences with this topic.

There is actually an RFC on this topic which I think basically says that rust-lang crates should support the previous two stable releases, but otherwise, there's no concrete policy. The RFC contains a discussion with a variety of opinions: https://github.com/rust-lang/rfcs/pull/1619
I asked about the release policy of clap here: https://github.com/kbknapp/clap-rs/issues/740 --- Opening this issue led to a policy where a minimum rustc bump was considered a minor breaking change, so that dependents could use the ~x.y syntax in their Cargo.toml and be guaranteed that a patch release will never bump the minimum Rust version.
Unfortunately, the new release policy of clap led to @joshtriplett opening this bug against ripgrep: https://github.com/BurntSushi/ripgrep/issues/271 --- Basically, the ~x.y syntax prevents ripgrep from compiling with newer versions of clap, even if it could. The interesting point brought up in this thread by @joshtriplett is the questioning of whether ripgrep itself should require a minimum Rust version. The thinking here is that the ability to compiler ripgrep master on a distro's (potentially) ancient version of Rust isn't particular valuable in and of itself, but only if that distro enables packaging Rust applications easily. In that sense, folks should be able to just install ripgrep from their distro and not need to compile it.
@alexcrichton also notes issues with ~ dependencies: https://github.com/kbknapp/clap-rs#warning-about--dependencies
I did eventually change the clap dependency to remove the ~ dependency: https://github.com/BurntSushi/ripgrep/blob/256aeb55468d57a179447c8b2cd64ada998987c5/Cargo.toml#L35 --- As a result, I almost never run cargo update, but rather, cargo update -p {crate}.
Maintaining a minimum Rust version in the face of dependencies without that same policy is a maintenance burden: https://github.com/kbknapp/clap-rs/pull/967 --- and that in turn sometimes has unintended consequences: https://github.com/kbknapp/clap-rs/issues/1003
A more circumspect interaction with the encoding_rs crate, where the outcome was this: https://github.com/hsivonen/encoding_rs#rust-version-compatibility --- Even getting specific pinned versions in the CI config was a huge win, but the policy here is, in short, "probably like clap's, but no promises."
Regardless of what ideals we all want to believe, users will try and use their distro's version of Rust to compile Rust applications, and when it fails, they will get frustrated: https://github.com/BurntSushi/ripgrep/issues/302

I think that's it as far as my own experiences go. It has been a struggle, but sometimes I wonder whether it is a natural struggle or not. This is why I think making the release policy of a crate discoverable is a first good concrete step we can take that will improve the situation for everyone, and I think it should be uncontroversial. (I think a minimal release policy is putting a pinned Rust version in a CI config.)
My own personal views on this have historically been a little hardline in the sense that I thought it was a semver breaking change. But I've grown increasingly soft on that particular issue. The end result is that I am intensely ambivalent. Therefore, I wind up on the conservative side of things because I'm not sure what to do. That is, all of my crates are pinned to a specific Rust version and I only ever bump the minimum Rust version with a semver version bump.
My conservative stance on this is what has been preventing me from pulling the trigger to release regex 1.0, for example. I really want to use SIMD optimizations in regex, but if I release regex 1.0 now, then under my conservative policy, I wouldn't be able to use SIMD unless I either released regex 2.0 or put the support behind a feature flag that is disabled by default. (At least, I think I could do that.) Either choice is a huge pain and not ideal at all. I suppose we shouldn't necessarily be afraid of making many semver version bumps ("so what if I release regex 2.0"), but every time I do that, some portion of the crate ecosystem is going to build both regex 1 and regex 2 into their crates, which aside from being just plain weird is going to hurt compile times quite a bit!
I have been considering what I think of as the clap compromise for regex though, because I also think it's weird to be holding back from regex 1.0 because of this. In particular:

regex 1.x promises API compatibility.
regex 1.x.y promises Rust compiler compatibility.

Invariably, this results in the same suggestion that clap makes: if you care about Rust compiler compatibility, then use ~1.x in your Cargo.toml, which in turn creates other problems I've highlighted elsewhere. I think my own personal take is that this is a decent compromise, and that I'd prefer the problems associated with the clap compromise over the problems associated with "be conservative" and the problems associated with "move fast and break things."

I still wish that a crate's minimum rustc could be expressed to cargo, as well as minimum std and cargo if we don't conflate all of these.  Then cargo could just use that for dep-solving, pruning out versions from the registry that are too new for the toolchain in use.  That still requires crates to be diligent about declaring their requirement, hopefully with CI to prove it, but it would be better than the status quo.
There have been a few RFCs started along these lines, and I admit I just sat back on the assumption that things were headed on the right track.  Can anyone summarize what's happened with that?

@cuviper Rough summary: any kind of version specification depends on new features in Cargo and Cargo.toml, so these efforts blocked on things like Cargo unstable features and versioning of the Cargo schema itself. I think https://github.com/rust-lang/rfcs/pull/2182 is the next step there, and once we have that we can introduce a means of handling rustc.

For things like SIMD optimizations that don't affect the public API, there is a third option. You can check the rustc version in a build script and set appropriate CFGs to enable or disable the SIMD codepaths automatically. This does mean that you now have two implementations of a bunch of stuff, but that may already be the case if you're specifically targeting AVX or whatever.

Yeah that's what I meant by adding a feature. It's definitely a pain but yeah that might be what I end up doing.

It does seem like a proper solution to this isn't possible without help from cargo, but it also seems like we can all agree that bumping the minimum rustc version should at least be a minor version bump, and I doubt that's going to change even when cargo has a great, stable solution for this. So for the purposes of the API guidelines, it seems safe to recommend that everyone:

explicitly test a specific rustc version in their CI
make that version easy to find in your documentation
never bump the minimum rustc version in a patch release

Anything beyond that is probably overkill for a typical crate, but this is enough to make upgrading to a more elaborate policy easy if your crate ever becomes atypically popular, and it's enough to avoid putting an undue research burden on anyone that does need to support specific rustc versions.

Actually, I just noticed the current guidelines don't talk about CI or versioning at all. Are those considered out of scope?

I would personally like it if more crates were willing to release >1.0. In my opinion many crates are afraid to release 1.0 for fear of never being able to go beyond. Much of what is being discussed here could be alleviated if crates were more willing to bump the major.
I believe a major hesitation to many popular crates releasing a 1.0 is the fear of "getting something wrong" or not being able to take advantage of rustc advances by not being able to go beyond 1.0 as similarly described by @BurntSushi
I'm hoping as the "core" Rust crates start going beyond 1.0, it will become more acceptable, but don't see it happening without the "core" or very popular libraries doing it first as they generally set the tone and guidelines. Personally, I also think the, "Never a Rust 2.0" is partially contributing to this phenomenon.
This is by no means a call for crates to quickly release a 1.0 followed immediately by a 2.0. But I do wish more crates were willing to bump the major as issues like what's being discussed evolve naturally. I believe if we had more willingness to bump the major, this would probably a be a non-issue.
I'm also just as guilty, as even though clap went 2.0 quite quickly, I've been extremely hesitant to go 3.0 for fear of getting "too far ahead of the norm, and therefore something is wrong" which is admittedly a little silly. As mentioned above, I don't think the ~x.y should be the defacto solution, and perhaps create more problems than they solve. As @BurntSushi said, there are very valid reasons for both sides of the argument.
For now though, I see the above three bullet points mentioned by @lxrec as being a better policy than none at all.

A bump of the required rust version should be treated as a a breaking change of your library in the sense of semver. It breaks the cargo update workflow for anyone who is not always on latest Rust stable, and this is not good.
Is it enough if you bump the minor version? No! That means that anybody who has caret requirements anywhere inside their dependency chain might get their cargo update workflow broken, and caret requirements are definitely too popular inside the rust community.
If one day we might be getting a "minimum rust version required" field in Cargo.toml, and cargo update gets changed to not update a dependency if the newer version has a too new required rust version, I think that requirement can be loosened.

@est31 I strongly disagree with any statements that a bump of required Rust version must always be released as a breaking change. Whatever advice we end up giving here will be primarily a discussion around evaluating tradeoffs, not a hard line.
If I have a library that miraculously compiles on Rust 1.3.0 and is used by thousands of downstream crates and I discover a performance problem that would be fixed by using Box::from_raw, my options are:

Live with the poor performance for the rest of forever,
Bump the minimum Rust version to 1.4.0 in a breaking change, forcing months of ongoing breakage as a thousand libraries upgrade,
Write unsafe code to do it myself (a future version of Rust would be free to break my unsafe implementation and cause memory unsafety),
Freely use Box::from_raw in a minor version. Zero people in the world still care about 1.3.0.

It is pretty clear to me which of these I would do and lose no sleep over.

@dtolnay This is an argument of the form "if I remove this public function nothing bad will happen because who really uses it and doing a breaking change would require people to update".
I really hate how staying up to date on the current crates.io ecosystem is unusable if you have installed your rustc copy from your distro or are pinning your rust compiler for some other reason. I don't say that people should not rely on Rust 1.4.0 but at least don't break existing projects.
If you are on an older compiler you aren't even getting compilation errors like "sorry, but your Rust compiler is too old", the errors are more often of the form "function not found" or "this feature is unstable".

And libc is literally inside the top two of most directly depended upon crates, so it is an exceptional example.

It is an argument of the form "evaluate the tradeoffs and take the least bad approach rather than adhering to dogma."

An issue with bumping the major upon increasing the minimum required Rust that I haven't seen mentioned yet is the affects of signaling "minor breaking changes"
With Rust having a very quick 6 week release schedule, it's not inconceivable that a library maintainer may want to take advantage of new features every few Rust releases (or at max every release).  Speaking from experience, there always seems to be that new hot feature I can't want to be stabilized. If it's advised to bump the major, it's conceivable that libraries could have very rapid major bumps.
Library consumers have no way to know if a bump of a major is a real breaking change (non additive change of API surface, major shift of how to use, etc.) from things like minimum required Rust. I believe this would lead to more uses of version = "*". This system incentives staying on old rustcs, or never releasing 1.0.
There is no way to say, "I'm using the latest stable and don't care about minimum required Rust changes, but I do care about breaking changes." You're effectively forced into the current ~x.y scenario, without the ability to opt out.
I'd be curious to know if that scenario is any different to a package maintainer (Linux, macOS Homebrew, etc.). @joshtriplett do you have any insight for such a scenario and if it'd be any different from the ~x.y issues (e.g. library releases many major bumps and applications/consumers are spread across a large range of majors)?

@kbknapp For packages of Rust crates within a distribution, it's helpful to get an indication when the minimum Rust version has changed, and once we have metadata for that then we can track that in package dependencies. However, any given library crate should only get uploaded once the distribution has a sufficiently new rustc and cargo, and once it does the dependency won't matter, so this is mostly a matter of helping to make sure that gets checked before uploading.

Library consumers have no way to know if a bump of a major is a real breaking change (non additive change of API surface, major shift of how to use, etc.) from things like minimum required Rust.

When updating to a new major version I already now first just update it and try whether the build still works. If it does it is a good indication that nothing major changed in the API.
@kbknapp it seems that your point (as well as my previous point about cargo update breaking if you just allow minor version upgrades) will get moot once we can actually track required version information via the metadata. Because then one doesn't have to require that the required version gets bumped only with a major semver release (as cargo update can take the metadata information into account). So see my proposal only scoped to libraries that do not track the required version.
Btw, as for verifying the required version I think the best idea is to check whether the currently running compiler matches the required version at package time. We already do a compilation here to verify whether the crate compiles. A more sophisticated variant would be to optionally use rustup to possibly download the specified minimum version and then do the build with that version. It can be made really convenient and the same time really accurate (unless you upload to crates.io via CI, or you implement some other mechanism that automatically transports the build status for the minimum required version from CI to the computer where you do the packaging, CI is not really accurate in ensuring that the version specified in the metadata actually can still build the project).

@dtolnay, you wrote:

If I have a library that miraculously compiles on Rust 1.3.0 and is used by thousands of downstream crates and I discover a performance problem that would be fixed by using Box::from_raw, my options are:

and listed options 1 to 4. Would there not be an option 5:

Write conditionally compiled code that takes advantage of the new Box::from_raw function. Enable this code conditionally at compile time based on the version of rustc being used.

With that option, you would be respecting the semantic versioning (and thus keep the expectations of your downstream dependencies) and you would get to make things better/faster/easier for users with newer compilers. This is the same as what @sfackler suggesed doing about the SIMD support.
So to that end, maybe the focus should be on enabling such cases? Make it super easy and low-effort to opt-in to new features in the code. I don't think it's possible today to do conditional compilation with #[cfg] based on the rustc version?
That is, I'm imagining writing something like this:
#[cfg(semver_compat(rustc_version, "< 1.4.0"))]
fn make_me_a_box() -> Box<Stuff> {
    // slow way...
}

#[cfg(semver_compat(rustc_version, ">= 1.4.0"))]
fn make_me_a_box() -> Box<Stuff> {
    Box::from_raw_parts(...) // yay, the fast way
}

That is, make it easy to swap out the implementation of a function

without having to declare new Cargo features
without having to use a build script

This way the overhead of supporting new APIs requires less ceremony — you pay with some internal conditional logic. Importantly, downstream users won't have to see or deal with with this complexity, they only get the benefit. Their code won't suddenly stop compiling — and if they use a newer compiler, they'll see the code become faster.

@mgeisler That would be nice. I believe you can achieve something similar today with build.rs shenanigans. IIRC, there was pushback on adding version specific cfgs (they have been brought up before), but I can't remember the specific reasoning.

Back-referencing my thread describing real-life breakage that was reported to me.
All I’d like to point out is that CI won't help with detecting breakage for crates which aren’t routinely running CI (i.e. maintainership mode, rare commits, etc.).
Other than that it seems to me that some ability to specify rustc versions supported by the crate in Cargo.toml will be necessary. The rustc_version-like cfg could be implemented as a procedural macro thing and doesn't really need explicit compiler support.

@mgeisler That would be nice. I believe you can achieve something similar today with build.rs shenanigans. IIRC, there was pushback on adding version specific cfgs (they have been brought up before), but I can't remember the specific reasoning.

@BurntSushi Yeah, I cannot imagine that it hasn't been suggested before :-) — this kind of inline feature detection is basically what people have been doing for decades with Autoconf for languages like C. The Python ecosystem also makes liberal use of such "seamless degradation" by importing missing libraries for older versions of Python. In my opinion, it works quite well.
I haven't published many Rust libraries, but I've already noticed that my code breaks from time to time, even when I don't make changes. It breaks because of my dependencies which bump the required rustc version. It's not very satisfying to see Travis fail from one run to another with no changes to my code and no changes to the compiler version. A community that prides itself on using semantic versioning should not accept this.
With a Rust release every 6 weeks, having support for the most recent stable versions means having support for ~3 months. That seems extremely short to me. Compare this with a language like Python where good Python libraries also support at least the 2-3 most recent recent releases — but Python releases are roughly one per year.

I have two cents and I'd like to put them in.
I believe that requiring a new minimum rust version should not be considered a breaking change. My reasoning is twofold:

I believe that Semver, which Rust and its libraries have decided to go with, is only concerned with public API changes, and that the compiler version does not constitute affecting the public API. It's possible that you could interpret Semver to include compiler versions as the public api, but I believe the spirit is that it's only concerned with the API, ie. the code.
Consider if it was a breaking change - major version bumps now mean two very different things to the developer. In one case, an actual API change occurred and they must change their code accordingly, and in the other they simply need to update their Rustc version and should not change any code.

This is a bit of a pain point for Rust because its a young language that's being rapidly iterated on, but I think the dust will settle and it doesn't change what a breaking change is meant to signify. I agree the rustc compiler version requirement should be described somewhere, just not here. Python's setup.py has a spot for minimum required version, I'm sure lots of other package managers do too.

Hi!
I've realised that I feel strongly about this issue and that I, unlike most of the commentors here, think that bumping a required rustc version should never be a major semver bump. Note that I don't maintain any high profile rust libraries, so my argument comes from fist principles and though experiments, and may not stand well against the reality :-)
The crucial observation is bumping the minimal supported rustc version (msrv from now on) is not viral.
Consider package foo 1.0.0, which depends on bar = "1.0.0", such that msrv for them is 1.30. Suppose now that new bar 1.1.0 is released, which bumps msrv to 1.32.
I argue that msrv for foo is still 1.30. Indeed, any application, that uses foo, can be compiled with 1.30, if it has bar locked to 1.0.0 in the lockfile. To change foo's msrv, one need to change the line in Cargo.toml from bar = "1.0.0" to bar = "1.1.0", as that would indeed prevent any application, which depends on foo, to use rustc 1.30. More formaly, msrv for the library is max of msrv for library's own code and msrv of minimal versions of its dependencies.
Libraries don't actually know which rustc and which specific minor versions of dependencies would be used. It is for the application (leaf crate) to decide. By not bumping major version after bumping msrv, libraries actually give the most flexibility to the application. In the foobar example, the application which uses foo and, transitively, bar may lock bar to 1.0.0, if it needs to be compatible with rustc 1.30, or it may lock bar to 1.1.0, if it is fine with requiring rustc 1.32 and wants to take advantage of bar's recent improvements (perhaps 1.1.0 added super-fast SIMD optimizations :-) ). Note that foo does not care at all which minor version of bar the application ends up picking.
In contrast, major version bump significantly decreases flexibility. Suppose that, instead of bar 1.1.0, bar 2.0.0 was released, which only bumps msrv, and otherwise is API compatible with bar 1.0.0. This puts foo in a peculiar position, because now it must choose which version of bar to pick, 1.0.0 or 2.0.0. Neither choice is better than other, because 1.0.0 has lower msrv, but 2.0.0 is, say, faster (because SIMD). And the application either becomes locked into bar 1.0.0, or bar 2.0.0, or, quite probably and worse, pulls both versions of bar from different dependencies.
So, that's it for the theory. In practice, library authors need to run CI to verify msrv, and, if done naively, it'll break with suggested strategy, because Cargo always picks the latest minor versions. The simplest way to fix that is, for msrv part of CI, to use lockfile even for libraries. An even better solution should be available soon: nightly cargo has a --minimal-versions unstable flags, which forces the resolution to prefer lowest minor versions. The original purpose of this flag was to check, during CI, that minimal versions of dependences, specified in Cargo.toml, are in fact correct (that is, to verify that you don't depend on features, introduced in spam 1.3.0, if you have spam = "1.2.0" in toml). I think this flag would also work perfectly to check that msrv of you library is what you think it is.
For applications, we really need to poke some Cargo folks with sharp sticks, so that they teach Cargo to generate lockfiles using only packages with specific msrv. That is probably not going to happen soon, so for the time being cargo update -p foo seems like the best strategy. Note, however, that it is perfectly fine for applications to use ~ and = requirements in Cargo.toml, so cargo update + incremental tilde or eq pinning of offending deps in Cargo.toml might also be a viable strategy.
With all that in mind, I think the following are some reasonable guidelines:
For libraries:

Never bump major version to only bump msrv.

Never restrict the upper version of your dependencies to maintain msrv, because upper versions don't affect msrv by matklad's definition of msrv.

Have CI setup running cargo test, using stable compiler, without lockfile. This job should be run daily, because it may fail if some dependency publishes bad version.

Have a documented msrv and a CI setup running cargo test with it. This setup should use either a lockfile, or the --minimal-versions flag.

For any CI setup, which uses a specific compiler version, use pinned dependencies (lockfile or --minimal-versions).

For binaries:

Publish lockfile to maintain msrv.

Use CI to verify msrv.

Consider using = or ~ in Cargo.toml, to make generation of new lockfile easier.

Be careful when updating dependencies, use cargo update -p and check msrv afterwards.

For applications, we really need to poke some Cargo folks with sharp sticks, so that they teach Cargo to generate lockfiles using only packages with specific msrv.

In order for Cargo to be able to do that, you'd need to specify the msrv in Cargo.toml... with rustup integration cargo could even download the msrv on cargo publish and check the crate before publishing. I think the guidelines saying that you should do this would be a good compromise.

The simplest way to fix that is, for msrv part of CI, to use lockfile even for libraries.

This sounds like the key guideline to me. Is the lockfile distributed as part of cargo publish ?

This sounds like the key guideline to me. Is the lockfile distributed as part of cargo publish ?

The lockfile of a library has no effect on the downstream crates. The guideline was specifically about CI of the library itself, and it would be obsolete when --minimal-versions flag is stable.
At present, we don't include lockfiles in published crates, however there's an unstable feature to do this, as it is useful for binaries to make sure cargo install foo always picks the same dependencies.

I find the resistance to upgrading ones stable rustc version very interesting since it's very different from my own perspective. Would it help guide this situation if a list of reasons to resist upgrading rustc was compiled?
I have a hard time figuring out why anyone would avoid upgrading when it's just a rustup upgrade away.

Well, the main reason to resist upgrading Rust is that upgrading the std library is a breaking change, and since there is no way to specify a std library version in the Cargo.toml, there is no way to defend against this.
For example, if we add a trait method from Itertools to Iterator, basically every crate using the Itertool trait method will break in the next Rust upgrade.
And that's the "best" case. The worst case is when we add something to the std library that silently changes the behavior of Rust programs, like an inherent method to any type in the std library API.

Note that the reasons for keeping tabs on Rust versions aren't just technical. They are also social:

Some environments strictly control what version of software that is used. This doesn't in and of itself imply a certain semver strategy, but I think it does at least help to have a coherent story about what version of Rust your code requires. Even being able to know that requires some work.
Some folks use distros with older versions of the Rust compiler. If you want to cater to those folks and let them compile your code, then you need to manage the version of Rust that your code requires.
In general, as a maintainer, I want to have a clear and unambiguous statement about which version of the Rust compiler my code requires to compile.

The various semver heuristics are one way of managing this, but there are other ways (like making Cargo.toml aware of the Rust version). Others have pointed out potentially serious flaws with the semver approach. So there's no obvious path forward here.

I don't know much about working in environments with strict rules on what software are allowed so I can't really contribute to that part of the discussion.
For crates.io I think it would be doable to run a big batch job of cargo build tests using all rustc versions and tagging each crate + crate version with compatible rustc versions. Maybe it would and should require some reasonable limit on rustc versions to test with, starting with the latest and going back a couple of stable releases.

In my opinion right now bumping the minimum required rustc version should be considered a breaking change (arguments already listed in the discussion above), but it should be only a temporary solution and we really should push for rustc field in the Cargo.toml, which will be used by cargo to select an appropriate crate versions. After we will get such capability, I think it will make sense to recommend for post-1.0 crates to bump minor version after changing the minimum rustc version. This will allow to easier publish fixes for serious bugs for crate versions which target older compilers.

Here is a crazy/wonderful approach that requires https://github.com/rust-lang/cargo/issues/5499.
Suppose Serde 1.0.x wants to bump the minimum required compiler version from rustc 1.13 to 1.29.

We publish Serde 2.0.0 with an implementation that requires rustc 1.29 (bear with me).
We go back to the code of Serde 1.0.x and add a semver-trick* dependency on serde = { version = "2.0", optional = true }. This is unlike the typical semver trick dependency in that it is an optional dependency! *you need to read this link or else nothing I write will make sense.
Still in Serde 1.0.x, we add a build.rs script which uses version_check to detect when we are being built by rustc >= 1.29. If so, print the magic line that turns on the optional dependency on 2.0.
In lib.rs of Serde 1.0.x we detect #[cfg(feature = "serde")] and if so, do the usual semver trick re-export of all the contents of 2.0.
If #[cfg(not(feature = "serde"))] then we provide everything as usual, everything as it exists in the 1.0.x series with a compiler requirement of 1.13.
Publish as the next release of 1.0.x series.

There are many steps but this is a modest amount of work for a significant library. The end state is:

Anyone on old compilers observes no change. Dependencies on serde = "1.0" continue to provide all the same APIs. You cannot have 2.0 in your dependency graph because your compiler does not meet its minimum version requirement.
On new compilers you get a semver-trick relationship where serde = "1.0" and serde = "2.0" are synonymous.

People who argue rustc requirement bumps are a breaking change are happy because their serde = "1.0" dependency can never pull in code that does not compile on their compiler version.
People who argue rustc requirement bumps are not a breaking change are happy because they get to use new compiler features without forcing an upgrade treadmill of major versions on their downstream users.

Still in Serde 1.0.x, we add a build.rs script which uses version_check to detect when we are being built by rustc >= 1.29. If so, print the magic line that turns on the optional dependency on 2.0.

This shouldn't work as far as I know because whether a given dependency is enabled or disabled is resolved before build scripts are run.

Slight modification that no longer requires https://github.com/rust-lang/cargo/issues/5499: we could have 1.x unconditionally depend on 2.0 and add a build script to 2.0 as well, which sets a feature on old compilers that turns the entire 2.0 crate into an empty crate.

I don't have strong feelings about the semver question here, but as someone maintaining a decent-sized Rust application I frequently run into situations where I update a dependency or add a new dependency and need to bump the minimum Rust version I support (which I test against in CI), but I find it virtually impossible to figure out what the actual required version is! It's easy to see that a PR breaks compiling against the pinned Rust version in CI, and often the error message will even name a specific feature that's unstable in that version, but there's no good way (AFAIK) to figure out what version stabilized that feature. (In other cases the error is not as clear and it's even harder.)

@luser Yeah, I run into the same problem. This is why I've been advocating that everyone put a specific Rust version in their CI config so that others can go and look at it and know what version the project intends to be able to compile on. I think that is an uncontroversial and unambiguously good step forward, and in particular, does not require everyone to agree on the semver ramifications---folks are free to bump the minimum Rust version as much as they want, they just have to do so explicitly.
I think more and more projects are doing this, but unfortunately, many still aren't. At that point, you're right, it's a research task to figure out the minimum Rust version. There's probably a script someone could write that does a binary search for you, but this requires having all intermediate versions of Rust installed. (rustup makes this easy, though, may take up a bit of disk space!)

(See also https://github.com/japaric/trust/issues/103 about running CI with a rust-toolchain file present)

See rust-lang/rfcs#2495 for a proposal which will allow authors to specify minimum supported Rust version (MSRV), which in combination with additional constraints in dependency versions resolution algorithm resolution algorithm will make changing MSRV backwards compatible change.

@luser same here, although I must say that while this is pretty annoying when it happens, it doesn't happen often enough to me to be a continuous annoyance. As in, when it happens, I bisect the version required, and don't have to worry about it again for a couple of months.

An interesting idea from @Eh2406 for a CI setup that should work today.
To test MSRV, one can use
cargo +nightly -Z minimal-versions generate-lockfile && cargo +MSRV test

Caveats:

your crate probably won't build with minimal-versions right off the bat, see 1 and 2 for the list of problems you may face.

-Z minimal-versions itself is unstable.

I'm using latest stable as MSRV for the crates I maintain. Hopefully better tools will appear to handle this for everyone more gracefully.

TL;DR: Strong opinion; have better error message; not a breaking change

Like others said, the main problem is that you don't get a nice error message about it. This would remove all the pain for my personal use of Rust.
I don't think this should be considered as a change:
rustc is not gcc, we all? use rustup that allow to install and update rust on every common OS. People don't need to wait 1 year a .dep from debian stable to update rustc. I agree some project could have some trouble updating rust, but this should be settled by freezing the specific version of each dependency. Let's imagine ~5% of projects and I think it's much less, would have trouble to keep rustc up-to-date. That mean ~95% of users will "pay" for these ~5%, I don't think it's worth it when there is already an easy solution for these ~5%. (Also, I doubt these ~5% want to have a lot of dependency)
Semver is about API, it's doesn't have a way to express compiler version. rustc version is a meta dependency, this is not possible to include it in semver. "edition" in cargo should be enough, but in my opinion, it's clearly a way to hide a Rust 2.0. I mean, maybe I'm totally wrong, but between 2015 and 2018 edition, there is obvious breaking change. Ok, have edition make this smooth but if you try, for example, the diesel get started guide, you will have a cargo.toml with edition = 2018 but the guide didn't expect that, some code in the guide will not compile because diesel example use self in use statement. Also, you are forced to use "macro_use" even if you want to use 2018 edition because you can't import table macro.
2018 edition despite all these changes, I never saw someone complaining about update their code. I always saw, "wow nice this is so much better", I think Rust is too afraid of being seen as an unstable language because of pre-1.0. But Rust dev are in the majority not afraid of little change, on the contrary the community always asks to improve Rust. I agree Rust must not change like pre-1.0 but there is a big difference between change everything every month and change little thing sometime. Anyway, we already have this reputation, people often stick to their first impression.
I already feel like some big crate were living in the past (I don't need to name them) and I hope there will not limit themselves just for few use cases. Of course, I don't encourage to always use the last release, but I think using 3-6 months release is perfectly acceptable, for me these are 3 versions of rustc, stable, beta (who use beta :p) and nightly. And we should have a nice error message that just ask to update rustc.

Here's a hacky PoC cargo-subcommand to generate a "quick" list of the MSRV by crate version for a particular crate. The idea being maintainers could list this data in their README and allow downstream consumers to make a more informed decision about upgrades and such.
https://github.com/kbknapp/cargo-msrv-table

Crates could specify it in Cargo.toml as package metadata? cargo metadata gives manifest paths to dependencies, so tool only needs to read manifests. Would Just Work among varying dependency versions, and where not specified the tool could just try compiling it based on your selected MSRV?

@kbknapp nice tool! Some suggestions:

Usage of bisection instead of linear search
Maybe incorporating the versions found out for earlier crate releases? Usually it should be close, so maybe test the version itself as well as the version before and behind before starting bisection.
Right now cargo doesn't respect MSRV during resolution, so your results will show too recent MSRVs. One can patch cargo's resolver to treat cargo releases with an MSRV prior to a certain version as yanked, as long as you have MSRV info for those crates.
I recommend building a database instead of letting crate maintainers do it. This way, the new feature requires no buy in from the maintainers who are often even hostile to the MSRV concept (yet their code is still being relied upon). That database can be filled by automated tools running in the cloud or something.

@est31 great suggestions! The tool was meant to be more a proof of concept than a full blown project. If someone wants to foster that command into a real solution I'd be happy to help along where I can and also grant full access.
I agree some sort of database would be more usable, even if it was some sort of combination of local/"cooperative" crates instead of a full search. However, that also adds a lot of complexity, and potentially cost to such project.


Add @karenhchu and @bridgetkromhout as a project maintainers on brigadecore/blog

This issue formally invites existing maintainers to vote on adding Karen Chu (@karenhchu) and Bridget Kromhout (@bridgetkromhout) as a maintainers specifically on the brigadecore/blog project.
Both Karen and Bridget are valued collaborators who have already been reviewing blog posts for quite some time, but without the ability to formally sign off. Making them maintainers will streamline the process of publishing peer-reviewed content to the blog.
If each of these nominations is ratified, the corresponding nominee would be added to the blog-maintainers group in this org. That group is already listed as a CODEOWNER for this repository. They would also be added to the public maintainers document.
We do not have a formally defined method of voting in new maintainers but the guidelines require that we have a majority vote. The current list of eligible voters include org maintainers @technosophos @vdice @radu-matei @krancour and repo maintainer @flynnduism.
The vote will be opened until Jan 18, 2022 or until at least 3 voters approve.
To vote, simply add a +1 comment or statement on this issue. Be sure to indicate which nominee(s) you are +1'ing.

+1 for both Bridget and Karen
🎉

+1 for both from me, of course.

+1 🎉

The motion carries.


Change Page event, how to intercept

Hello to everyone,
Does anybody know if it is possible to hanlde page change event ? How do you listen to click on the paginator ? how do you get the page number and do some custom action ?
I did not find any solution to this.

Also interested in this.

Also interested in this.

Also interested in this.

Hi, you could use the particular observable property in the data source to determine if page change occurs.
let data: LocalDataSource = new LocalDataSource();

this.data.onChanged().subscribe(change => {
	switch (change.action) {
		case 'page':
			this.handleSmartTablePageChange(change);
			break;
		case 'sort':
			this.handleSmartTableSort(change);
			break;
	}
});

Best regards

Hi, you could use the particular observable property in the data source to determine if page change occurs.
let data: LocalDataSource = new LocalDataSource();

this.data.onChanged().subscribe(change => {
	switch (change.action) {
		case 'page':
			this.handleSmartTablePageChange(change);
			break;
		case 'sort':
			this.handleSmartTableSort(change);
			break;
	}
});

Best regards


how could I just train brdf network only with an existing mesh and multiview images

Should I do some coords align or something? Thanks!

I have made it,thanks. BTW,the result seems not to be good on my custom dataset.

How to improve the quality?


Modify admin password in docker image

Is it possible to modify the default password in the docker image?

Do you want to modify it? Or can you pick it from logs if I generate random one?


Test case for HXLM-Action: datasets from Translation Initiative for COVID-19 "TICO-19"

Webpage: https://tico-19.github.io/
Research paper: https://tico-19.github.io/data/paper/ticopaper.pdf
(fork) https://github.com/fititnt/tico-19.github.io

While not crucial to implement the V1 of hxltm-action, this issue will be used to reference strategy used to convert this real dataset as test case for conversion. The end result both could be useful and also help to understand what additional tooling could be relevant.

TODO: add more context.

One visible challenge: TICO-19 does not have any multilingual with more than 2 languages
Even without the idea of HXLTM (it does not even existed when TICO-19 started, we're both new to @HXL-CPLP, and I don't remember of this initiative past there, or I would 100% be interested in get in) the data repository does not have any "global" dataset for terminology. Even the terminology is released using bilingual CSVs (I think have some ID for concepts, but the research paper mentions they way the languages were structured make then non-uniform). But bilingual files is not really the best way to organize terminology.
My complaint here is that maybe no one guessed about release as TermBase eXchange (TBX) (which is supposed to be the de facto industry standard, even if I totally understand it lack A LOT of tooling make hard).
Possible hypothesis
The non-tooling part
The research paper mentions both pivot languages and the fact that some languages had more review than others. So, with this alone is likely that some way to merge back some multilingual terminology, what Europe IATE would call reliabilityCode would not be the same.
In other words: we could here "merge" the files back together, but the best would be this be done by who worked on the project. Also, they did not stored comments from translators about issues they had, so not just because I saw some of translations (not just Portuguese) have some minor issues (like translate WHO to WHO, not OMS, this on the Facebook/Google datasets), but whoever use this dataset on future may still keep non-perfect translations.
Also, very likely the Facebook/Google have more issues because the source text in English already was shitty. I'm saying this because lack of language diversity on such companies make no one aware how hard is to translate terms without any context.
The tooling part
This compressed README https://github.com/tico-19/tico-19.github.io/blob/master/data/TM/README.md.zip make me suspicious why they did not used TBX

Use this directory to upload the Translation Memories.
TMX files were created with the Tikal script of the Okapi Framework
https://okapiframework.org/wiki/index.php/Tikal_-_Conversion_Commands#Convert_to_TMX_Format

Way back there on https://github.com/EticaAI/HXL-Data-Science-file-formats/issues I remember trying to use the okapi to convert CSVs (as the ones on HXL) to TMX and TBXs.
The Okapi does not support TBX (https://okapiframework.org/wiki/index.php/Open_Standards#TBX_-_Term_Base_eXchange). And other tool that support TBX, the https://toolkit.translatehouse.org/ (see http://docs.translatehouse.org/projects/translate-toolkit/en/latest/commands/csv2tbx.html) since it's internal format is mono or bilingual, simply the tooling itself cannot handle multilingual terminology.
So, even if TBX was, in theory, good to merge the end result, to get translation back from Translators Without Borders, the people who compiled the end project would need to create own tooling, and this means read about entire TBX.

I will take some sleep and continue tomorrow (so whatever I'm writing here is not full reviewed).
TBX do have less tolling, but unless the source content for data/TM (which may be the CSVs) already was reduced to have none extra relevant information, the use of Translation Memory eXchange (TMX) (https://en.wikipedia.org/wiki/Translation_Memory_eXchange) instead of XLIFF (XML Localization Interchange File Format) (https://en.wikipedia.org/wiki/XLIFF) to store translations actually is less powerful.
Any decent tool focused on translations have support for XLIFF. Even open source ones like https://www.matecat.com/ allow export translators annotations, and even do some automated tagging and checks, and the user can rearrange the source text when it is poor written (which is not hard for source text in English).
Why not TMX (instead of XLIFF) for translations
TMX is a dead standard. And store only language pairs still not fix the big picture.
It's only supported by most machine learning and etc, because is simple to implement, but is beyond recognition for serious usage on language pairs.
I think that the TMXs files where generated later (so, they are not really losing information, because it was already stored first without any more relevant context), but for cases where translations already are stored on XLIFF, TMX is a downgrade. And I'm saying this because is bizarre the idea of trying to apply a lot of machine learning and etc to detect accuracy of translations and not care about how this is collected and stored.
If either Facebook or Google employees read this comment on next years, for gods sake, take some time and implement proper parsing of XLIFF. TBX is fair better, but most translations tools would export XLIFF as best output format.
The not-so-irony relation with TBX and helicopter research

Context: https://en.wikipedia.org/wiki/Neo-colonial_science

One reason to implement more support for data that collect more input from translators (instead of just over-reduce to only what machines can understand) is that is it resemble helicopter research

Our QA process revealed that in most cases the problems arose when the translators did not have any medical expertise, which lead them to misunderstand the English source sentence and often opt for sub-par literal or word-for-word translations.

This part of the paper seems to ignore the fact that most of these languages, actually the translators were doing word-for-word translations because the languages themselves may never had the term for such concepts. This word-by-word strategy is mentioned for example on Arabic https://www.researchgate.net/publication/272431518_Methods_of_Creating_and_Introducing_New_Terms_in_Arabic_Contributions_from_English-Arabic_Translation.
My point here is even the lack of store additional metadata from translators (like their comments) as would be possible with any minimal tool compatible with XLIFF would allow to see why they were failing.

We additionally release the sampled dataset along with detailed error annotations and corrections (...) Although small in size (at most 558 sentences in each translation direction), we hope that releasing these annotations will also invite automatic quality estimation and post-editing research for diverse under-resourced languages.

The paper mention somewhere will have at least some annotations. So maybe I just did not find on the zip files, so 60% of my written rant here can be wrong. But I don't think they can archive so high accuracy, when even source text have at least punctuation like commas missing.

Quick proof of concept (merging only 4 languages in 3 different files) here : hxl proxy link. This link may stop working if test files are changed (which is likely).
As long as the working languages are well defined, the hxltmdexml can convert easily from the TMX to CSV. With HXL proxy humans can merge datasets one by one. But since every column is different (have information about the language, different from the TICO-19 terminology, where the language is a column, so merging all data is just append the CSVs aware that there is heading in each one)
Current screenshots


[Streaming] Replace runtimeStatsText() with usage in examples

Recently we added usage to the last chunk in streaming if the user specifies streamOptions: { include_usage: True} in the request, to be compatible with the latest OpenAI API; for more see https://github.com/mlc-ai/web-llm/pull/456.
This PR updates our streaming examples to use chunk.usage instead of runtimeStatsText(). It is expected that we will deprecate runtimeStatsText() in the future. Currently, only low-level API forwardTokenAndSample() still needs it as they do not use OpenAI API (e.g. examples/logit-processor).
Such examples include:

simple-chat-ts
simple-chat-js
next-simple-chat
streaming (already updated)

Example output for simple-chat-js:


Unable to open GeoIP2 database: /usr/share/GeoIP/GeoIP.dat

Hello,
I am trying to use GeoIP2 but I run into the following error:
$ sudo goaccess --config-file temp.conf

GoAccess - version 1.2 - Mar 30 2018 15:52:01
Config file: temp.conf
Fatal error has occurred
Error occurred at: src/geoip2.c - init_geoip - 92
Unable to open GeoIP2 database: /usr/share/GeoIP/GeoIP.dat

My configuration file is attached.
I am running Ubuntu 18.04 beta.
The following is a line from my nginx access.log, some parts have been censored.
<mysite> <ip.address> - - [22/Mar/2018:19:58:13 +0000] "GET / HTTP/1.1" 301 185 "-" "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0"
I got my GeoIP database from installing libmaxminddb-dev from the Ubuntu package library. I have tested the database using geoiplookup.
$ geoiplookup -f /usr/share/GeoIP/GeoIP.dat <IP_ADDRESS>
GeoIP Country Edition: US, United States

I compiled GoAccess from source using the following parameters:
./configure --enable-utf8 --enable-geoip=mmdb --enable-debug --enable-tcb=btree --with-openssl
temp.txt

Please make sure you are using the mmdb database.

For GeoIP2 City database:
wget -N http://geolite.maxmind.com/download/geoip/database/GeoLite2-City.mmdb.gz
gunzip GeoLite2-City.mmdb.gz

For GeoIP2 Country database:
wget -N http://geolite.maxmind.com/download/geoip/database/GeoLite2-Country.mmdb.gz
gunzip GeoLite2-Country.mmdb.gz

That worked, thank you :)
Please consider updating the GeoIP section of the config template that confused me a lot

Thanks. Should be there a few lines below.

yeah I'm not sure how I missed that.
I got confused because the config you get from http://tar.goaccess.io/goaccess-1.2.tar.gz doesn't have it :(

Got it. I may have missed that. Thanks for pointing that out. Should be there in the next release.


Add support for title attribute in mj-button

This is added to the last element, a or p as the title attribute similarly to name. Closes #2175

Not sure if a version bump or other stuff related to maintaining is required in this project.

We'll bump everything on release thanks for this !


[Feature] CPU implementation

Following up on #15, this would allow more widespread utility of the package.

As mentioned in #15, CPU implementation has been added.


how about the qulity of the batched faster-whisper？

from faster_whisper import WhisperModel, BatchedInferencePipeline
model = WhisperModel("medium", device="cuda", compute_type="float16")
batched_model = BatchedInferencePipeline(model=model)
Batched version improves the speed upto 10-12x compared to openAI implementation and 3-4x compared to the sequential faster_whisper version. It works by transcribing semantically meaningful audio chunks as batches leading to faster inference.
Will reatimeSTT support the batched version?
Thanks!

Will look into that.


[CT-3012] [Bug] dbt docs generate takes a lot of time

Is this a new bug in dbt-core?

[x] I believe this is a new bug in dbt-core
[X] I have searched the existing issues, and I could not find an existing issue for this bug

Current Behavior
Hi there,
I have seen issue #1576, but I think it still needs attention.
I am using dbt to transform data in Greenplum database. When generating catalog with command dbt docs generate, the process sometimes takes around 10 min.
After analysis of a query that is executed against database, I found out that there is no condition specifying tables that are needed and although I am working with ~20 tables, resulting set had 3.3 million records.
Is there a way to optimize the query that gets the metadata to be more efficient, or modify WHERE clause to decrease the size of result?.
Thanks.
Expected Behavior
I would expect the dbt docs generate command to finish generating the catalog within a minute as it is planned for production usage and a lot of pipelines.
Steps To Reproduce
standard dbt project with 20 tables.
run  dbt docs generate.
Have  around 50 000 tables in database.
Relevant log output
No response
Environment
- OS: wsl Ubuntu 22.04
- Python: 3.10.12
- dbt: 1.5.0

Which database adapter are you using with dbt?
No response
Additional Context
No response

Thanks for reaching out @SamuelBohumel !
It is a known case that catalog generation time is outsized in comparison to the actual number of dbt models in cases like these:

source schemas with many thousands of tables, of which a small subset are actually referenced by dbt models
lots of non-dbt objects living in the same schemas as dbt models/seeds/snapshots/etc

One option for you

Is there a way to optimize the query that gets the metadata to be more efficient, or modify WHERE clause to decrease the size of result?

There is! I haven't tried it myself, but you can do something like the following:

Since dbt-greenplum inherits get_catalog from dbt-postgres, copy this macro definition into your local project.
Rename postgres__get_catalog to greenplum__get_catalog
Optional sanity check before the next step:

Try out dbt docs generate again; it should yield the same results and take the same amount of time as before
Add and 1 = 0 to the where clause
Re-run dbt docs generate again; it should run fast, but not generate the full intended output
Remove and 1 = 0 from the where clause

Using catalog_2.sql compared to the default bigquery__get_catalog as a guide, add the relevant Jinja that will change the catalog query to filter on dbt objects only and not all objects in a schema. See below for details.

Filter on dbt objects only
Here are the key additions to include that filter within bigquery__get_catalog in the catalog_2.sql example above:
2a3,25
>   {# Here is where we build our list of relations of interest #}
>   {%- set relations_in_project = [] -%}
>
>   {%- for node in graph.nodes.values() -%}
>     {%- if node.resource_type == 'model' -%}
>       {%- do relations_in_project.append(node.alias) -%}
>     {%- endif -%}
>   {%- endfor -%}
>   {%- for source in graph.sources.values() -%}
>     {%- do relations_in_project.append(source.name) -%}
>   {%- endfor -%}
>
>   {# Make the list unique #}
>   {%- set relations_in_project = set(relations_in_project) | list -%}
35a59,64
>         {# Here is where we filter the relations so we dont simply fetch all of them #}
>         {%- if relations_in_project | length > 0 %}
>         and coalesce(REGEXP_EXTRACT(table_id, '^(.+)_{1}[0-9]{8}$'), table_id) in (
>             {%- for rel in relations_in_project -%}'{{ rel }}'{%- if not loop.last %}, {% endif -%}{%- endfor -%}
>         )
>         {% endif -%}

Note that Postgres/Greenplum, you don't need to worry about date-shared tables, so I don't think you would need the REGEXP_EXTRACT part.

Here is the full diff
2a3,25
>   {#
>   /*
>     This macro changes the catalog query to filter on dbt objects only and not all objects in a dataset.
>     The regex is very sensitive to the date sharding pattern of your tables so you may want to
>     change the regex of '^.+[0-9]{8}$' to '^.+[0-9]{6}$' if say your tables are shareded by YYYYMM
>     instead of YYYYMMDD.
>   */
>   #}
>
>   {# Here is where we build our list of relations of interest #}
>   {%- set relations_in_project = [] -%}
>
>   {%- for node in graph.nodes.values() -%}
>     {%- if node.resource_type == 'model' -%}
>       {%- do relations_in_project.append(node.alias) -%}
>     {%- endif -%}
>   {%- endfor -%}
>   {%- for source in graph.sources.values() -%}
>     {%- do relations_in_project.append(source.name) -%}
>   {%- endfor -%}
>
>   {# Make the list unique #}
>   {%- set relations_in_project = set(relations_in_project) | list -%}
26c49
<             REGEXP_CONTAINS(table_id, '^.+[0-9]{8}$') and coalesce(type, 0) = 1 as is_date_shard,
---
>             REGEXP_CONTAINS(table_id, '^.+[0-9]{8}$') and coalesce(type, 0) in (1, 2) as is_date_shard,
35a59,64
>         {# Here is where we filter the relations so we dont simply fetch all of them #}
>         {%- if relations_in_project | length > 0 %}
>         and coalesce(REGEXP_EXTRACT(table_id, '^(.+)_{1}[0-9]{8}$'), table_id) in (
>             {%- for rel in relations_in_project -%}'{{ rel }}'{%- if not loop.last %}, {% endif -%}{%- endfor -%}
>         )
>         {% endif -%}
207c236,240
<   {{ return(run_query(query)) }}
---
>   {%- do log(query) -%}
>   {%- set results = run_query(query) -%}
>   {%- do log(schemas ~ ' - rows returned: ' ~ results | length, True) -%}
>
>   {{ return(results) }}

Another option
If you have any control over which schemas the dbt dbt sources and models live in, then isolating them into dedicated schemas should also help.

Thanks for your quick response.
We have seen these solutions when looking for an issue with the performance of the catalog. Unfortunately, this does not solve our use case, as we are trying to enable users to use all filtering functionality (tags, lineage, etc.).
In our environment, we have been given little control over schema. We are working on one of the largest Greenplum database implementations, so there are thousands of users, and schemas are dedicated for security management rather than project separation.
You are correct, separating by schema would work as catalog uses this filter condition, but we would propose something like adding a flag to dbt docs generate that would only retrieve data from selected nodes (flag example: --only-selected). This also makes more sense to us, as the rest of the nodes are thrown away anyway.
We believe this could be useful in other implementations too, whenever there are more complex environments, and would also improve scalability.

Thanks for that additional info @SamuelBohumel

we would propose something like adding a flag to dbt docs generate that would only retrieve data from selected nodes

After discussing this with @graciegoheen, we think what you're asking for will be covered by https://github.com/dbt-labs/dbt-core/issues/4997 (which we've started working on) combined with https://github.com/dbt-labs/dbt-core/issues/6014, so I'm going to close this issue in favor of those two.
If you have any further insights, we'd appreciate your comments on either of both of those. Either way, you may want to subscribe to those so you can get notified of any updates.
Workaround in the meantime
In the meantime, you might be able to use the selected_resources context variable within a customized get_catalog macro in your project to speed up the execution time of the underlying query.
See below for a quick proof-of-concept (that I'll leave to you optimize as-desired).
At least two things to note in this implementation that could be improved:

looking for matches within the selected_resources is not optimized for time complexity -- it looks to me like it is O(n^2) when it could be better than that
if multiple schemas have tables with the exact same name, and only one is included within a --select, then this implementation of the query will include both

Proof-of-concept
Full customized version for postgres / greenplum:

Click to expand

{% macro default__get_catalog(information_schema, schemas) -%}

  {# Here is where we build our list of relations of interest #}
  {%- set relations_in_project = [] -%}

  {%- for node in graph.nodes.values() -%}
    {%- if node.resource_type == 'model' -%}
      {%- if node.unique_id in selected_resources -%}
        {%- do relations_in_project.append(node.alias) -%}
      {%- endif -%}
    {%- endif -%}
  {%- endfor -%}
  {%- for source in graph.sources.values() -%}
    {%- do relations_in_project.append(source.name) -%}
  {%- endfor -%}

  {# Make the list unique #}
  {%- set relations_in_project = set(relations_in_project) | list -%}

  {%- call statement('catalog', fetch_result=True) -%}
    {#
      If the user has multiple databases set and the first one is wrong, this will fail.
      But we will not fail in the case where there are multiple quoting-difference-only dbs, which is better.
    #}
    {% set database = information_schema.database %}
    {{ adapter.verify_database(database) }}

    select
        '{{ database }}' as table_database,
        sch.nspname as table_schema,
        tbl.relname as table_name,
        case tbl.relkind
            when 'v' then 'VIEW'
            else 'BASE TABLE'
        end as table_type,
        tbl_desc.description as table_comment,
        col.attname as column_name,
        col.attnum as column_index,
        pg_catalog.format_type(col.atttypid, col.atttypmod) as column_type,
        col_desc.description as column_comment,
        pg_get_userbyid(tbl.relowner) as table_owner

    from pg_catalog.pg_namespace sch
    join pg_catalog.pg_class tbl on tbl.relnamespace = sch.oid
    join pg_catalog.pg_attribute col on col.attrelid = tbl.oid
    left outer join pg_catalog.pg_description tbl_desc on (tbl_desc.objoid = tbl.oid and tbl_desc.objsubid = 0)
    left outer join pg_catalog.pg_description col_desc on (col_desc.objoid = tbl.oid and col_desc.objsubid = col.attnum)

    where (
        {%- for schema in schemas -%}
          upper(sch.nspname) = upper('{{ schema }}'){%- if not loop.last %} or {% endif -%}
        {%- endfor -%}
      )

    {# Here is where we filter the relations so we do not simply fetch all of them #}
    {%- if relations_in_project | length > 0 %}
      and tbl.relname in (
          {%- for rel in relations_in_project -%}'{{ rel }}'{%- if not loop.last %}, {% endif -%}{%- endfor -%}
      )
    {%- endif %}

      and not pg_is_other_temp_schema(sch.oid) -- not a temporary schema belonging to another session
      and tbl.relpersistence in ('p', 'u') -- [p]ermanent table or [u]nlogged table. Exclude [t]emporary tables
      and tbl.relkind in ('r', 'v', 'f', 'p') -- o[r]dinary table, [v]iew, [f]oreign table, [p]artitioned table. Other values are [i]ndex, [S]equence, [c]omposite type, [t]OAST table, [m]aterialized view
      and col.attnum > 0 -- negative numbers are used for system columns such as oid
      and not col.attisdropped -- column as not been dropped

    order by
        sch.nspname,
        tbl.relname,
        col.attnum

  {%- endcall -%}

  {{ return(load_result('catalog').table) }}

{%- endmacro %}

Diff of customized version vs. the default implementation:

Click to expand
3a4,20
>   {# Here is where we build our list of relations of interest #}
>   {%- set relations_in_project = [] -%}
>
>   {%- for node in graph.nodes.values() -%}
>     {%- if node.resource_type == 'model' -%}
>       {%- if node.unique_id in selected_resources -%}
>         {%- do relations_in_project.append(node.alias) -%}
>       {%- endif -%}
>     {%- endif -%}
>   {%- endfor -%}
>   {%- for source in graph.sources.values() -%}
>     {%- do relations_in_project.append(source.name) -%}
>   {%- endfor -%}
>
>   {# Make the list unique #}
>   {%- set relations_in_project = set(relations_in_project) | list -%}
>
37a55,62
>
>     {# Here is where we filter the relations so we do not simply fetch all of them #}
>     {%- if relations_in_project | length > 0 %}
>       and tbl.relname in (
>           {%- for rel in relations_in_project -%}'{{ rel }}'{%- if not loop.last %}, {% endif -%}{%- endfor -%}
>       )
>     {%- endif %}
>

Let us know it goes if you try it out!

Hi,
I've tried that workaround with macro and time for generating a catalogue has decreased rapidly.
Thank you very much!

See below for a version of get_catalog that improves the time complexity when looking for matches within the selected_resources.
It also includes a stand-alone get_selected_relations macro that can be reused in an adapter-independent manner.
Overall, the implementation still has this remaining issue though:

if multiple schemas have tables with the exact same name, and only one is included within a --select, then this implementation of the query will include both

get_catalog restricted to only selected resources

Click to expand
{% macro postgres__get_catalog(information_schema, schemas) -%}

  {%- call statement('catalog', fetch_result=True) -%}
    {#
      If the user has multiple databases set and the first one is wrong, this will fail.
      But we will not fail in the case where there are multiple quoting-difference-only dbs, which is better.
    #}
    {% set database = information_schema.database %}
    {{ adapter.verify_database(database) }}

    select
        '{{ database }}' as table_database,
        sch.nspname as table_schema,
        tbl.relname as table_name,
        case tbl.relkind
            when 'v' then 'VIEW'
            else 'BASE TABLE'
        end as table_type,
        tbl_desc.description as table_comment,
        col.attname as column_name,
        col.attnum as column_index,
        pg_catalog.format_type(col.atttypid, col.atttypmod) as column_type,
        col_desc.description as column_comment,
        pg_get_userbyid(tbl.relowner) as table_owner

    from pg_catalog.pg_namespace sch
    join pg_catalog.pg_class tbl on tbl.relnamespace = sch.oid
    join pg_catalog.pg_attribute col on col.attrelid = tbl.oid
    left outer join pg_catalog.pg_description tbl_desc on (tbl_desc.objoid = tbl.oid and tbl_desc.objsubid = 0)
    left outer join pg_catalog.pg_description col_desc on (col_desc.objoid = tbl.oid and col_desc.objsubid = col.attnum)

    where (
        {%- for schema in schemas -%}
          upper(sch.nspname) = upper('{{ schema }}'){%- if not loop.last %} or {% endif -%}
        {%- endfor -%}
      )

    {# Here is where we filter the relations so we do not simply fetch all of them #}
    {%- set relations_in_project = get_selected_relations() %}
    {%- if relations_in_project | length > 0 %}
      and tbl.relname in (
          {%- for rel in relations_in_project -%}'{{ rel }}'{%- if not loop.last %}, {% endif -%}{%- endfor -%}
      )
    {%- endif %}

      and not pg_is_other_temp_schema(sch.oid) -- not a temporary schema belonging to another session
      and tbl.relpersistence in ('p', 'u') -- [p]ermanent table or [u]nlogged table. Exclude [t]emporary tables
      and tbl.relkind in ('r', 'v', 'f', 'p') -- o[r]dinary table, [v]iew, [f]oreign table, [p]artitioned table. Other values are [i]ndex, [S]equence, [c]omposite type, [t]OAST table, [m]aterialized view
      and col.attnum > 0 -- negative numbers are used for system columns such as oid
      and not col.attisdropped -- column as not been dropped

    order by
        sch.nspname,
        tbl.relname,
        col.attnum

  {%- endcall -%}

  {{ return(load_result('catalog').table) }}

{%- endmacro %}

{% macro get_selected_relations() -%}

  {# Here is where we build our list of relations of interest #}
  {%- set relations_in_project = [] -%}

  {%- for selected_resource in selected_resources -%}

    {%- if selected_resource in graph.nodes -%}
      {%- set node = graph.nodes[selected_resource] -%}
      {%- if node.resource_type == 'model' -%}
        {%- do relations_in_project.append(node.alias) -%}
      {%- endif -%}

    {#- -- This section is commented out since sources can't be selected
    {%- elif selected_resource in graph.sources -%}
      {%- set source = graph.sources[selected_resource] -%}
      {%- do relations_in_project.append(source.name) -%}
    -#}

    {%- endif -%}
  {%- endfor -%}

  {# Make the list unique #}
  {%- set relations_in_project = set(relations_in_project) | list -%}

  {{ return(relations_in_project) }}

{%- endmacro %}

Logic to share across adapter implementations
See below for a diff of customized version vs. the default implementation that can be used to inform the implementation of each dbt adapter.
The reuasable portion that is adapter-independent has been abstracted into a stand-alone macro.

Click to expand
1d0
<
37a37,45
>
>     {# Here is where we filter the relations so we do not simply fetch all of them #}
>     {%- set relations_in_project = get_selected_relations() %}
>     {%- if relations_in_project | length > 0 %}
>       and tbl.relname in (
>           {%- for rel in relations_in_project -%}'{{ rel }}'{%- if not loop.last %}, {% endif -%}{%- endfor -%}
>       )
>     {%- endif %}
>
53a62,91
>
>
> {% macro get_selected_relations() -%}
>
>   {# Here is where we build our list of relations of interest #}
>   {%- set relations_in_project = [] -%}
>
>   {%- for selected_resource in selected_resources -%}
>
>     {%- if selected_resource in graph.nodes -%}
>       {%- set node = graph.nodes[selected_resource] -%}
>       {%- if node.resource_type == 'model' -%}
>         {%- do relations_in_project.append(node.alias) -%}
>       {%- endif -%}
>
>     {#- -- This section is commented out since sources can't be selected
>     {%- elif selected_resource in graph.sources -%}
>       {%- set source = graph.sources[selected_resource] -%}
>       {%- do relations_in_project.append(source.name) -%}
>     -#}
>
>     {%- endif -%}
>   {%- endfor -%}
>
>   {# Make the list unique #}
>   {%- set relations_in_project = set(relations_in_project) | list -%}
>
>   {{ return(relations_in_project) }}
>
> {%- endmacro %}

For anyone following here, https://github.com/dbt-labs/dbt-core/pull/8772 allows for the usage of --select within dbt docs generate, and it is shipping in dbt-core v1.7.


GoAInputMonth doesn't function in FireFox

If you need help putting your report together
Get in touch with the design system team on Slack at #design-system-support
Describe the bug
Currently when the REACT Component  is used in Firefox the mask isn't shown (MMMM, YYYY). Additionally, we cannot provide valid input for the form when used in Firefox.
What is the level of criticality
Currently when a user opens our application FireFox, they cannot provide this input so prevents the user from completing the form.
To Reproduce (include pictures or video if helpful)
Steps to reproduce the behaviour:

Navigate to our dev application to month/date field.
Autocomplete / valid input cannot be selected.

Expected behaviour

A clear and concise description of what you expected to happen.

System configuration
Desktop (please complete the following information):

OS: Windows 11
Browser FireFox
Version 101.0.1

Firefox:

Chrome:

@PeterLuuGoA Can you provide a browser version as well?

Hey @PeterLuuGoA are you able to replicate the issue with the date input on our docs site?
https://ui-components-ui-components-dev.os99.gov.ab.ca/?path=/docs/components-inputs--types
Can you also post the code snippet for the for the image that you posted?

@PeterLuuGoA I missed that it is the month type that you are using and not the datetime. For this there Firefox doesn't offer support for it yet.

https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/month#browser_compatibility

@PeterLuuGoA Can you provide a browser version as well?
Browser FireFox
Version 101.0.1

Firefox does not yet offer support for type="month". This issue can only be resolved once Firefox supports this type.


Add acts/scenes list to full text tab

This PR implements a Segments component that lists acts and scenes of a play and adds this list to the full text tab of the play details page.
It builds upon the typescript fixes of #187.
NB: In mobile view the list is still rendered after the text. This should be adjusted in the grid setup.
partially solves #76

Great job!
Last two commits take care of grid placement on mobile and add some margin between acts for a clearer visual division.
Green light for merging from me 🟢


Unable to uninstall completely

Hi there, I want to uninstall youtube-music using brew uninstall command:
brew uninstall --cask youtube-music

But after I checked with the brew list command, it's still there although it says it has been uninstalled.
I also tried this command but it doesn't work
brew uninstall --cask th-ch/youtube-music/youtube-music

After all, I was able to uninstall using this command:
brew uninstall --force th-ch/youtube-music/youtube-music

👋 Glad to hear force worked, I guess it depends on how it was installed (typically using --cask or not)  - hopefully with the instructions in https://github.com/th-ch/homebrew-youtube-music/pull/3 it should work better!


Add accessible text to Status

When rendering a status, we should always provide accessible text
because the icon is hidden to a screenreader via the aria-hidden
attribute. We also provide the title attribute for sighted users when
hovering with a mouse.
https://fontawesome.com/v5.15/how-to-use/on-the-web/other-topics/accessibility#web-fonts-semantic

@darreneng: I know this is a very old issue, but would it be possible to take another look at it and perhaps see about using the ariaLabel prop on the Icon? That should do what we want.
Also, many of the awesome testing improvements you included here are now part of react-gears.

Closing since ariaLabel prop is the preferred method of achieving this, and the testing improvements have been implemented elsewhere.


Update README.md

provide correct file with test credentials
update version people are told to install

that failure is an existing file that isn't formatted.  I've formatted it in #151.

:green_heart: :blue_heart: :purple_heart: :yellow_heart: :heart:


PDM thinks Penny Dreadful Saturdays 6.02 had 9 people in the top 8.

For some reason in Penny Dreadful Saturdays pdm thinks metalatog also made top 8 and is one of the 3/4 position people which makes 9 people. [Here](http://gatherling.com/eventreport.php?event=Penny Dreadful Saturdays 6.02) is the actual order/placing in gatherling for reference.

Three people dropped with records that would get them in to top 8 to cause this fun and games. Updated manually but if we ever re-scrape from Gatherling this will return. Doesn't seem worth making special code for as it should be rare!


[Feature Request]: Switch to row-oriented dictionary for GetResult and QueryResult

Describe the problem
The return objects for GetResult and QueryResult are confusing to many users right now as they require you to match data up to your input ordering as well as internally in the result.
Describe the proposed solution
We should change GetResult and QueryResult to be row oriented dicts with id keys, or similar.
{"id" : {"embeddings", "distances", "metadata", "documents"}}
Alternatives considered
Sorting the results based on input ids. This doesn't always work (the case of ids and a where clause) and also doesn't solve all the problems
Importance
would make my life easier
Additional Information
No response

Would it be acceptable if this were a class function rather than a complete refactor?

What about a QueryResult and GetResult Object in Python.
What about a QueryResult and GetResult Interface in Typescript.
"Skate to where the puck is going"
On another note, as Chroma adds more features and complexity grows, simple objects intuitively fitting in a simple model will be the best approach to reduce complexity.

can confirm the column oriented query results are very disorienting.
if api compatibility is a concern, at least add documentation examples to mark it as column oriented, and add builtins to convert to row oriented


N7: Deploy to Cloud Production Deployment

Description
Deploy the web application on AWS cloud to ensure scalability, high availability, and security.
Acceptance Criteria

The web app should be accessible via a public domain.
AWS EC2 or Elastic Beanstalk is used for deployment.
The app should auto-scale based on traffic.
SSL/TLS is set up for secure communication.

Technical Requirements

AWS EC2 or Elastic Beanstalk for application hosting.
AWS S3 for static asset storage.
AWS Route 53 for domain management.

Dependencies

Domain name registered on AWS Route 53.
VPC and security groups setup for EC2 or Elastic Beanstalk.

Notes/Comments

Ensure proper IAM roles are created for security and access control.
Consider using AWS CloudWatch for monitoring and logging.

#115 #123


Account create error

I am trying to access the open ai after creating the resource group and subscription resource for open ai api but an error occurs in the subscription area where it does not recognize the subscription provided. When I looked at the documentation, it does not show the command to enter the subscription but in the training for openai the command is different. Please suggest!

Hi @Sidzeppelin95 - are you using the proxy we're providing? If so, then you don't have to create an AOAI resource.
But if you do want your own AOAI resource - in that command, you can skip the --subscription option altogether and it'll use your default subscription to create the resource on.
Or - put single quotes around the subscription name.
Or, you could enter az account list and you'll then see a bunch of subscriptions that you have access to. Assuming you have permissions to create resources on the subscription you want to use - you can swap to it by using az account set -s <NAME OR ID OR SUBSCRIPTION
Probably more info than you were after, but I hope it helps.


[Doc] Revise and update the dev mode documentation

Is your doc request related to a problem? Please describe or add related issue ID.
Developer Mode Installation is outdated.

Close, it's a dev document.


Config Contexts Not Applying Correctly

Environment

Nautobot version (Docker tag too if applicable): v1.5.12
Python version: 3.9
Database platform, version: Postgres
Middleware(s): k8s/Rancher

Steps to Reproduce

Create 2+ dynamic groups with devices associated with any kind of filters.
Create a config context filtered by any other object, or unfiltered.
Create config context objects in a git repository applied by dynamic group, and sync to Nautobot.
View the "rendered context" in the Device>Config Context view.

Expected Behavior
Config contexts filtered by dynamic group, should only apply to the devices which are members of that Dynamic Group.

Observed Behavior
All config contexts will be applied in the rendered context (and then returned with GraphQL or Golden Config intended config generation). The correct contexts are shown in the "Source Contexts", and the "extra" contexts are not shown here, just in the rendered context. This was not an issue prior to this feature being "feature flagged".

Hmm, that last sounds suspiciously like a caching issue. Just to confirm, cacheops is disabled in your deployment?

Hmm, that last sounds suspiciously like a caching issue. Just to confirm, cacheops is disabled in your deployment?

Yes it is disabled

Okay, I think I've narrowed down the problem. It appears that the incorrectly merged contexts are being added by the config context data annotation. We didn't update that queryset to account for dynamic groups, so the context that is applied only by dynamic group ends up matching everything (I think).
I'm not sure what the correct course of action is for fixing this.

I applied similar logic to line 132 to apply dynamic groups to base_query and although that appears to properly add the context to the "source contexts" but still is not filtering in the rendered context. Looking for more guidance on what to look at next.

@johanek we have a concern about potential performance impacts with this solution, especially when retrieving config contexts via API. Do you have any way of testing your use case at scale?

@abates what does testing the use case at scale mean to you?
For context, I'm looking to create ~12 Dynamic Groups, each would have a single config context assigned to the group. The dynamic groups each will contain between 2-10 devices.
I'm happy to do some testing if you can walk me through what you'd like done. You're welcome to message me on the NTC slack to discuss this as well 👍

@abates OK, it doesn't take much scale to see the performance impact with the solution is very problematic. I now have 15 Dynamic Groups and ~900 devices, and when applying the patch any request will timeout (60s) using the REST API to query devices and when accessing /dcim/devices/ via the UI.
So that's not really workable sadly. Please let me know how I can help any more.

we might have hit the problem in a different way:
We have nested tenant groups - up to three in depth. The result is that config context is not applied at all to those devices belonging to tenants which fall under the nested group. When the tenant groups contain only tenants, it works as expected.

any chance?

Hi @vladanmilosevic73, if your problem pertains to tenants/tenant groups rather than to dynamic groups, would you mind opening a separate issue?

Thanks Glenn, I created https://github.com/nautobot/nautobot/issues/4768 for the nested Tenant Groups being affected

Thank you, this slipped down the inbox quietly. Sorry for slowness.