[FEATURE] Support for multiple backup locations

Is your feature request related to a problem? Please describe.
While Longhorn supports replication across servers, it does not support adding multiple backup locations. With some hosts, one S3 compatible endpoint for instance equals one datacenter. In order to support off-site backups for these hosts, being able to configure two (or more) backup locations could tackle this. Perhaps you're simply using multiple hosts for backups.
Describe the solution you'd like
I'd like to be able to configure a list of backup locations, and have backups we created at every location. When restoring from a backup, you could potentially choose where you want the backup to be loaded from.
Describe alternatives you've considered
I haven't found an alternate solution.
Additional context
No additional context.

Leaving a note here, related #1761

Currently longhorn only supports a single backup target.
In the future we want to refactor the backup mechanism, to allow for multiple backup targets.
That refactor is not scheduled yet, see #1761.

The backup refactor is out there for 1.2. The Backuptarget CRD is a thing now. Are we able to specify multiple Backuptarget CRDs with different names?

Answering my own question: https://github.com/longhorn/longhorn-manager/blob/dd8e20c76dcd740db4301f3e37cb314e15a01b5e/controller/backup_target_controller.go#L120

Let's follow up https://github.com/longhorn/longhorn/issues/5411 instead.


GUACAMOLE-699: Update german translations

Updated the main german translation and added translations for the extensions.
I also switched the translation from a non-formal ("Du") to the formal ("Sie") expression.
Please note that i can't test the extension-translations, but checked them against a JSON-Validator.
Feel free to contact me through Jira for questions / clarifications (https://issues.apache.org/jira/browse/GUACAMOLE-699)

Please also squash your commits if there is no logical change worth citing in the message. Repeating the same "GUACAMOLE-699: Add initial german translation" message seven times doesn't add any value to the history.

@leetxyz: Wondering if you can fix up these issues so that we can merge these changes:

Remove translation strings that are not actually translated
Squash commits.

Dear all
Sorry for the delay, was on holiday.

I squashed the commits
I added the translations the guac-manifests

For the unneeded translations and @APP-Notations, could you please give me an example?
thanks and best regards

@mike-jumper: Not sure on some of these what should be left and what should be removed...

Lines for empty strings (fields with no headers, empty field options, etc.)?
Lines that refer to other lines (@:APP.PARAMETER, etc.)?

Lines for empty strings (fields with no headers, empty field options, etc.)?

These should be kept if the empty string is the correct German translation for what is represented by an empty string in English (probably the case).

Lines that refer to other lines (@:APP.PARAMETER, etc.)?

Same here - these should be kept if the translation as written is correct for German (assuming the line being referenced with @: exists in the new translation - angular-translate can't reference strings across translations).
The general rule is to omit strings which are untranslated because the translator couldn't or didn't translate them. If the string has been translated and just happens to be the same in both languages, then it should be duplicated. The current exceptions to this are APP.NAME and APP.VERSION which we only want defined in one location for simplicity and support for downstream branding.

Dear @berndhose
Thank you for your support, went through all comments and should have fixed them all and updated the PR.

The only issues I see are:

The entries within the translations array in guac-manifest.json should be maintained in alphabetical order.
Indentation should use spaces, not tabs (the new lines in the various guac-manifest.json have been indented with tabs)

Other than the above, looks good to me.

1. The entries within the `translations` array in `guac-manifest.json` should be maintained in alphabetical order.

Should be fixed.

2. Indentation should use spaces, not tabs (the new lines in the various `guac-manifest.json` have been indented with tabs)

Should be fixed.
I also found missing de.json references in auth-jdbc and auth-ldap and added them.

Looks great to me.


Add sf::Angle

Thanks a lot for making a contribution to SFML! 🙂
Before you create the pull request, we ask you to check the follow boxes. (For small changes not everything needs to ticked, but the more the better!)

[x] Has this change been discussed on the forum or in an issue before?
[x] Does the code follow the SFML Code Style Guide?
[x] Have you provided some example/test code for your changes?
[ ] If you have additional steps which need to be performed list them as tasks!

Description
Adds sf::Angle, a type safe representation of angles. Similar to sf::Time, sf::Angle provides an API for working with angles and provides named functions for converting to and from degrees and radians.
This PR is related to the issue #717
Tasks

[ ] Tested on Linux
[ ] Tested on Windows
[x] Tested on macOS
[ ] Tested on iOS
[ ] Tested on Android

@kimci86 semi-related to this PR, I think SFML needs a header with constants. Right now I can't think of a constant we'd need besides pi but it at least means removing a bunch of instances of PI all over the place. Something like include/SFML/System/Numbers.hpp that will contain sf::priv::pi among potentially other constants.

https://github.com/ChrisThrasher/SFML/commit/6e0eef46a19d6754887546bd9f690156b60e7cde
I tried to find as many redefinitions of pi and replace them with a single definition. Because we can't use C++20's <numbers>, this is the next best thing.

SFMLBuildMaster: Build this please.

Right now I can't think of a constant we'd need besides pi

Tau: τ = 2π
Not as common as pi, but still exists, in use, and related.

In my opinion, it would make sense to make the pi constant available wrapped in an sf::Angle as we are trying to make angle computations more explicit and safe. Maybe sf::Angle::Straight.
However, a potential problem I see is that 2.f * sf::Angle::Straight would evaluate to a zero angle. A full angle is not representable. It makes sense but I can imagine it might surprise users.
For example, consider something * 2.f * sf::Angle::Straight and 2.f * sf::Angle::Straight * something.
Anyways, it is already easy to write potentially surprising expressions such as 0.1f * 360_deg.
If really needed, pi would be available with sf::Angle::Straight.asRadians().
It is very verbose though, so sf::pi could stay.
In addition, I think sfml examples should be updated to use sf::Angle and not compute angles using primitive types. Maybe this can be a separate PR for later? I could do it if you are not eager to do it.

I am starting to think that angles should not be normalized in order to have commutative multiplication (at least as much commutative as float multiplication).

Not 100% sure I can follow – it's associative either way?

-5° * 18 = -90° = 270°
-5° * 2 * 9 = -10° * 9 = -90° = 270°
-5° * 9 * 2 = -45° * 2 = -90° = 270°
355° * 18 = 6390° = 270°
355° * 2 * 9 = 710° * 9 = 6390° = 270°
355° * 9 * 2 = 3195° * 2 = 6390° = 270°

Sorry, I should have given examples. Here:

(2 * pi) / 3 = 0
2 * (pi / 3) = 2.09439510239 rad = 120 °

Surprising things might happen when multiplying with non-integer values (1/3 in this example).

Ah, yeah, true!
Should probably follow your typical vector example and just provide a convenient way for normalization.
This just begs the question how (in)equality should be handled. Since mathematically, 0° and 360° aren't necessarily the same, but by common definition they would be.

@Bromeon

We should also add comparison operators.

Your later example about unintuitive comparison operators is why I didn't include those operators. It doesn't always make sense to say what angle is bigger than another since these angles are analogous to points on the perimeter of a circle. Comparison operators might make more sense with a [-pi, pi) domain but I'm not sure if I want to use that domain.

This is a problem that doesn't exist with floats (sure, the user has to do wrap-around themselves, but it typically means they're aware of how it works).

This is the argument for using C 😄. If users want supreme flexibility at the expensive of expressiveness then C is always available.

Just as another note against forced normalization: You actually might want to define an angle bigger than 360°. Imagine wanting some animation to do two full rotations, so you might want to tween from 0° to 720°. With normalization you wouldn't move at all.

@Bromeon

Your later example about unintuitive comparison operators is why I didn't include those operators. It doesn't always make sense to say what angle is bigger than another since these angles are analogous to points on the perimeter of a circle. Comparison operators might make more sense with a [-pi, pi) domain but I'm not sure if I want to use that domain.

True, but we already have that problem anyway -- not having comparison operators just makes people write
a.asRadians() < b.asRadians(), which is subject to the same issue, only less readable.
You bring up another good point: some people want a [0°, 360°[ range, others a [-180°, 180°[ one. Some don't care at all.
And Mario brought up yet another reason why this might be a bad idea.
Maybe we should instead add two methods to explicitly normalize and let the user decide?
Angle Angle::clamped180() const; // [-180°, 180°[
Angle Angle::clamped360() const; // [   0°, 360°[

@MarioLiebisch

Just as another note against forced normalization: You actually might want to define an angle bigger than 360°. Imagine wanting some animation to do two full rotations, so you might want to tween from 0° to 720°. With normalization you wouldn't move at all.

for (int angle = 0; angle <= 720; ++angle)
    object.setRotation(sf::degrees(angle));

Maybe I'm misunderstanding you but I'm not sure how this would be a problem. You can make any number of angles between 0 and 720 degrees. As far as the user is concerned, they don't even have to know that normalization is happening. The API doesn't stop you from making bigger angles. The tests do that many times to make sure the API is still correct when users do that.
@Bromeon

True, but we already have that problem anyway -- not having comparison operators just makes people write
a.asRadians() < b.asRadians(), which is subject to the same issue, only less readable.

If a user deliberately breaks out of the type safety of the API then I'm not sure what to tell them. It's the same as writing std::chrono::milliseconds(10).count() > std::chrono::seconds(1).count(). .count() is useful but dangerous. Same argument goes for asRadians and asDegrees.

You bring up another good point: some people want a [0°, 360°[ range, others a [-180°, 180°[ one. Some don't care at all.
And Mario brought up yet another reason why this might be a bad idea.

https://github.com/SFML/SFML/issues/1747#issuecomment-764708732
Earlier this year you how SFML tries to be simple and isn't trying to be Boost. Giving users access to control angle ranges (even if only via const member functions) is working against the idea of SFML being simple. I think the first thing we can agree upon is that we shouldn't let users pick the range of angles we use. Once we offer that control we can never take it back and it goes against the ethos of keeping things simple.
As for whether or not normalization should occur, it's already happening. See the definition of sf::Transformable::rotate. That normalization logic got removed in this PR because it's now encapsulated in sf::Angle. Imagine a user repeatedly calling sf::Transformable::rotate(sf::degrees(10)); to show an object spinning forever. Internally that float would grow unbounded. Because SFML chooses to not provide our own operator<< overloads, a user would then have to call asDegrees to print the angle to the console just to see something confusing like<PHONE_NUMBER>386719 which most would find surprising and not particularly helpful. Run that code long enough and they'll just see inf or NaN.
I hope we can come to agreement what range of normalization to use, but I think we should certainly have some degree of normalization to prevent users (including elsewhere in SFML) from having think hard about how to avoid these pitfalls.

As I understand, the first purpose of sf::Angle is to not be confused by units. This is achieved.
Then I see two concerns:

Taking care of precision by normalizing values, avoiding the angle going towards infinity.
Being usable intuitively in any arithmetic epxression.

Even though 1. is nice, 2. seems more important. Among what have already been pointed out, it allows uses like:
for(auto angle = 0_deg; angle < 720_deg; angle += 10_deg)
    object.setRotation(angle);

If we agree going that way, users can manually take care of precision with the modulo operator.

Thanks for the elaborate answer!

Maybe I'm misunderstanding you but I'm not sure how this would be a problem. You can make any number of angles between 0 and 720 degrees. As far as the user is concerned, they don't even have to know that normalization is happening. The API doesn't stop you from making bigger angles.

No, the user needs to know it.
sf::Angle a = sf::degrees(390);
a.asDegrees() // NOT 390

Clamping is not an implementation detail. Without users knowing the [0, 360[ semantics, they will write bugs.

If a user deliberately breaks out of the type safety of the API then I'm not sure what to tell them. It's the same as writing std::chrono::milliseconds(10).count() > std::chrono::seconds(1).count(). .count() is useful but dangerous. Same argument goes for asRadians and asDegrees.

By not providing an ordering relation, we force the user to break out of the type safety. Of course we can say "that's your problem", but in reality there are valid use cases for comparing angles and the currently proposed API does simply not enable them.

#1747 (comment)
Earlier this year you said how SFML tries to be simple and isn't trying to be Boost. Giving users access to control angle ranges (even if only via const member functions) is working against the idea of SFML being simple. I think the first thing we can agree upon is that we shouldn't let users pick the range of angles we use. Once we offer that control we can never take it back and it goes against the ethos of keeping things simple.

There are two choices we can make in the API:

Everything is implicitly clamped to [0, 360]. This means less work for the user, but can lead to surprises.
Angle is just wrapping a float. Conversions to a certain range are explicit, but thus also less error-prone.

I could agree that 1. were simpler if the clamping logic would "just work". But in fact this logic is a leaky abstraction, so the user must understand it in order to use Angle correctly. We make it appear simple, but the complexity is still there, just less obvious.
Several valid use cases, like bisecting an angle, become suddenly quite complex with this approach.

As for whether or not normalization should occur, it's already happening. See the definition of sf::Transformable::rotate. That normalization logic got removed in this PR because it's now encapsulated in sf::Angle. Imagine a user repeatedly calling sf::Transformable::rotate(sf::degrees(10)); to show an object spinning forever. Internally that float would grow unbounded. Because SFML chooses to not provide our own operator<< overloads, a user would then have to call asDegrees to print the angle to the console just to see something confusing like<PHONE_NUMBER>386719 which most would find surprising and not particularly helpful. Run that code long enough and they'll just see inf or NaN.

I don't see the problem here. If the code wants the rotation to be clamped, this is exactly where clampedTo360() comes into play.
Where I am not sure, is whether we always want that.

I hope we can come to agreement what range of normalization to use, but I think we should certainly have some degree of normalization to prevent users (including elsewhere in SFML) from having think hard about how to avoid these pitfalls.

Unfortunately I don't think it's possible to avoid all kinds of pitfalls. Ultimately, we need to ask ourselves what the task of sf::Angle is. I understood it as adding type safety against float, as well as enabling equivalent use of degrees and radians. You additionally understand it as limiting the domain (range) of allowed values. None is more correct, they just have different trade-offs.
When looking at existing gamedev libraries and linear algebra APIs, one thing I noticed is that almost none have a distinct angle type. Those who do (e.g. Rust euclid or Ogre3D) seem to do nothing more than wrap a float, sometimes even publicly. Maybe those issues we're encountering now were also encountered by them?

@Bromeon Safe to say that normalization won't be happening then. With that removed, can you elaborate on what extra member functions you'd want so I can implement and test those real quick?

@ChrisThrasher For now I'd start without implicit clamping. We still have the option to revise the semantics until the release of SFML 3.0.0; overall we need some practical experience with sf::Angle, as it's an entirely new thing for both SFML developers and users.
I would add these two methods, plus the relational operators < <= > >=.
Angle Angle::clampedTo180() const; // [-180°, 180°[
Angle Angle::clampedTo360() const; // [   0°, 360°[

That plus the available arithmetic operators probably cover most of the use cases.

@Bromeon I made those changes including tests for those two extra member functions.

I find the name "clamped" confusing because it reminds me std::clamp which has a different meaning. Sadly, I do not known a better alternative.

I find the name "clamped" confusing because it reminds me std::clamp which has a different meaning. Sadly, I do not known a better alternative.

Very good point, "clamp" actually means "limit to either edge".
Matlab uses wrapTo180 and wrapTo360, maybe we can adopt this?

I appreciate the feedback! I think I've addressed everything but let me know if I missed anything. Can we run the full pipeline now? I bet the 32 bit Mingw build will have some test failures due to its slightly different float point number handling. I probably just need to add Approx in a few more places in the tests.

SFMLBuildMaster: Build this please.

SFMLBuildMaster: Build this please.

SFMLBuildMaster: Build this please.

SFMLBuildMaster: Build this please.

SFMLBuildMaster: Build this please.

I reimplemented sf::Angle in terms of degrees instead of radians. Because SFML uses degrees and because degrees are generally easier for humans to reason about than degrees, it's a safe assumption to make that most users will construct an sf::Angle via sf::degrees and will print its value to the console via sf::Angle::asDegrees. By encoding angles as degrees, we minimize the number of floating point operators that occur which maximizes accuracy and minimizes the work that the computer has to do.

SFMLBuildMaster: Build this please.

SFMLBuildMaster: Build this please.

This should be ready now; or anything left to do? 🚀

No, I don't have any more work to do on this PR.

SFMLBuildMaster: Build this please.

I just pushed a new version of this commit which changes the naming of wrappedTo180 and wrappedTo360 to wrapSigned and wrapUnsigned. I mostly just copy-pasted what @Bromeon wrote but made a few small fixes to the Doxygen code to fix table formatting. This change should address all 3 outstanding unresolved issues which are all related to the naming and documentation of these functions.

SFMLBuildMaster: Build this please.

I found some more uses of sf::Angle mostly in the example programs.

SFMLBuildMaster: Build this please.

SFMLBuildMaster: Build this please.


MONDO_0017579 Baraitser-Winter cerebrofrontofacial syndrome reference to an ExactSynonym to an non-exist MONDO ID

Mondo term (ID Label)
Baraitser-Winter cerebrofrontofacial syndrome
Bug/Typo/Error description
The ExactSynonym of this term is Baraitser-winter syndrome, which reference to MONDO 0000719 (no longer a MONDO valid ID) via DbXref.
Your nano-attribution (ORCID)
0000-0003-2620-0345

Hi @linikujp thank you for submitting this issue!
The term MONDO:0017579 'Baraitser-Winter cerebrofrontofacial syndrome' has the db-xref to the obsoleted Mondo term MONDO:0000719 'obsolete Baraitser-winter syndrome' that was merged with this term.
Mondo maintains db-xrefs to Mondo terms that have been obsoleted and merged with another Mondo term as standard practice.
In this case, we have also included an additional db-xref for the syn  'Baraitser-winter syndrome,' Orphanet:2995. This will appear in the next Mondo release.
Please note that we are working on an automated pipeline to updated db-xrefs. Thank you!


fr translation

Translate all the page to french and add  a language switch button to header or footer section.

Use this links to get this few flags icons

May need some update if language choice more than two (02)

best way to do is by using a toggle menu or dropdown in header
use this youtube tutoriel as inspiration


SNOW-982017: snow object drop should have more helpful error message

SnowCLI version
SnowCLI Version: 2.0.0-alpha.1
Python version
No response
Platform
No response
What happened
Ran snow object drop

An unexpected exception occurred. Use --debug option to see the traceback.
Exception message:
'NoneType' object has no attribute 'lower'

Instead should have some clear error saying "missing required arguments object_type and object_name"
Ran snow object drop streamlit

An unexpected exception occurred. Use --debug option to see the traceback.
Exception message:
002003 (02000): SQL compilation error:
Streamlit 'STREAMLIT.SIS_APPS.NONE' does not exist or not authorized.

Instead should have some clear error saying "missing required argument object_name"
Console output
No response
How to reproduce
No response

Added checking not only for drop command #583

Merged


Biomes o Plenty water color issue with latest 1.9.2

Wetland has very Purple water.

Mangrove water is extra teal, which has a harsh contrast with the default water color of the roots when used with Dynamic Trees BoP.

The wetlands color was taken directly from BOP 1.16; here is a screenshot from that version. It looks like the same amount of purple to me (the biome changes to another one away from the shore, hence the lack of purple there).

I will see what I can do about the color mismatch for the Dynamic Trees roots.

I sent a PR to Dynamic Trees, as the issue is technically within their mod. Hopefully they accept it, if not I will have to patch their mod at runtime.

Hi, in latest 1.11.0, new error when "New Water=true":

when "New Water=false":

I made some more changes to texture handling in 1.11.0 as I have gotten a
number of requests to allow using the old textures. Apparently, this new
approach is not as widely compatible as I had hoped. I'll look into this
but it may take a couple of days.
On Fri, Feb 11, 2022 at 1:45 PM roccscout @.***> wrote:

Hi, in latest 1.11.0, new error when "New Water=true":
[image: image]
https://user-images.githubusercontent.com/71896090/153649368-00f7afdc-5b21-48d2-a6a5-21ccd00ffcac.png
when "New Water=false":
[image: image]
https://user-images.githubusercontent.com/71896090/153650731-ba275bd1-5ffc-41cf-b86a-79fcf8c9ad62.png
—
Reply to this email directly, view it on GitHub
https://github.com/Fuzss/aquaacrobatics/issues/70#issuecomment-1036510882,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AKHTVAHWISGGJY5BNX4GJULU2VKMTANCNFSM5NOKEUWA
.
You are receiving this because you commented.Message ID:
@.***>

I realized that this may be caused by the lack of the texture fix in https://github.com/DynamicTreesTeam/DynamicTrees/pull/669; give 1.11.2 a try.

This should all be fixed if you use the latest version of Aqua Acrobatics.


https://hub.github.com mv ./hub ~/bin should be mv ./bin/hub ~/bin

Or ./script/build -o ~/bin/hub as in your README.md.

Thanks!


Introducing wagmi Guru on Gurubase.io

Hello team,
I'm the maintainer of Anteon. We have created Gurubase.io with the mission of building a centralized, open-source tool-focused knowledge base. Essentially, each "guru" is equipped with custom knowledge to answer user questions based on collected data related to that tool.
I wanted to update you that I've manually added the wagmi Guru to Gurubase. wagmi Guru uses the data from this repo and data from the docs to answer questions by leveraging the LLM.
In this PR, I showcased the "wagmi Guru", which highlights that wagmi now has an AI assistant available to help users with their questions. Please let me know your thoughts on this contribution.
Additionally, if you want me to disable wagmi Guru in Gurubase, just let me know that's totally fine.

Not interested at the moment. Thanks!


feat(ts): add TSX support

Types of changes

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

Description
This PR provides better TS support, adding .tsx files support.
Vue SFC .vue with lang='tsx' should work too !
It uses a combination of 2 loaders :

ts-loader to transpile Typescript
babel-loader to handle JSX stuff

As for .ts files with loaders.ts, you can customize ts-loader options for .tsx files with loaders.tsx.
Documentation
As for other PR's related to the TS support, there will be a PR regrouping the whole TS support documentation, and a section about TSX will figure in it.
Checklist:

[x] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly. (PR: #)
[x] I have added tests to cover my changes (if not applicable, please state why)
[x] All new and existing tests are passing.

Codecov Report

Merging #4613 into dev will not change coverage.
The diff coverage is 100%.

@@           Coverage Diff           @@
##              dev    #4613   +/-   ##
=======================================
  Coverage   90.88%   90.88%
=======================================
  Files          61       61
  Lines        2206     2206
  Branches      536      536
=======================================
  Hits         2005     2005
  Misses        182      182
  Partials       19       19

Impacted Files
Coverage Δ

packages/webpack/src/config/base.js
95.29% <ø> (ø)
:arrow_up:

packages/config/src/config/build.js
85.71% <ø> (ø)
:arrow_up:

packages/builder/src/builder.js
96.7% <100%> (ø)
:arrow_up:

packages/common/src/utils.js
98.26% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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

@kevinmarrec Would you please locally resolve merge conflict?

@pi0 It should be alright now 🙂

@kevinmarrec are you working on documenting typescript feature as well?

@chanlito Sorry for late answer
Yes and I'll update the TypeScript example with the new setup :)


Component isn't compatible with React 16

I've been searching for a good currency input for React and that's the best I've found in a while. I started using it at some projects and had a great experience, but I couldn't use it recently since that specific project is using React 16.
Is there any interest of the community to do so? What would be needed? I could help if there is demand :)

It was actually an issue with yarn locking the package's React version to 15.6.0. Fixed it by editing the yarn.lock directly.


Size estimation for customer how not move data to M365 yet

Is your feature request related to a problem? Please describe.
Customers more often start to inform themself before starting the migration to M365. It would be nice to figure out
at this stage how many space they need to move onprem Exchange or Sharepoint to M365
Describe the solution you'd like
A way to get needed data from Exchange (must) and Sharepoint (nice to have because Sharepoint onPrem is rare)

Certainly possible, looking at the Exchange PowerShell module all the parts are there:
https://learn.microsoft.com/en-us/powershell/module/exchange/get-mailboxstatistics?view=exchange-ps
OR
https://learn.microsoft.com/en-us/powershell/module/exchange/get-exomailbox?view=exchange-ps
Same with the SharePoint:
https://learn.microsoft.com/en-us/powershell/module/sharepoint-online/get-sposite?view=sharepoint-ps
It'll need a bit more research; the other problem is that on-prem Exchange and SharePoint are, as you said, quite rare so testing could be an issue.


⚠ ClamAV has degraded performance

In f170766, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 704 ms

Resolved: ClamAV performance has improved in f19bf57.


GUI

Need to implement some sort of GUI framework. Probably code some from scratch.

Closing, made basic GUI system here 84f81808e79d969d0e41b61b935b5fd1f7298176


Do analysis of round-trip cocina descriptive data model

Dor-services-app is now able to round trip descMetadata to cocina description without persisting anything.  As h2 will require enabling updating using the cocina description, we must understand where the current descMetadata to cocina description is incomplete.  Thus we should write a script to round trip a sample set of descMetadata XML -> cocina description -> descMetadata XML and see what the differences are.
Get a sample of druids: https://sul-solr-a.stanford.edu/solr/argo_prod/select?fl=id&q=%3A&sort=random%20asc
This can be done by sshing to dor-services-app and running:
RAILS_ENV=production bin/validate-cocina-roundtrip

When this starts reporting that all records are successful, we should increase the sample size to several thousand.

Requires https://github.com/sul-dlss/dor-services-app/pull/1052

this is in the in progress column and isn't assigned to anyone.

Sort of on-hold right now until we unfreeze things.


dockerize the airavata codebase

provide a docker file that will create the docker image.

closed with the following commit:
https://github.com/airavata-courses/airavata-nextcoud/commit/33c8fee679d90f019a33d9d22d734e0ee7922431


refactor(runtime-core): use Object.entries

another PR of this file #250

Usually if you see a plain for loop in our source code, it is intentional for performance reasons. We are not accepting changes that introduce performance loss but doesn't change any behavior.


Implement language server

[x] Use https://github.com/Microsoft/vscode-languageserver-node-example as a base
[x] Update deps to use TS^2.0.3
[x] Move /extensions/html to node example

非常期待！

Related upstream issue: https://github.com/Microsoft/vscode/issues/15377

Released 0.2 which adapted VSCode's html extension into a language server for Vue.
IntelliSense is now available to html/css/js/scss/less.

How about ts in

@yeluoqiuzhi I don't think there is a standard way yet to use TS with Vue Single File Component.

yeah, so that we use seperated file, instead of Single file Component.
Just like vue-class-component

Aren't that just a TS file, where you don't even need <script lang="typescript">?

I want to write typescript in a Single File Component. Just use vue-ts-loader

I want to build better support for html/js/css/scss first, as these are the most popular ones.
The project you pointed to seems experimental. I won't spend time building support for it unless it gains traction.

@yeluoqiuzhi TS syntax highlighting is added, see #19. I'll see if I can do intelliSense later.


Fixed #31954 -- Fixed migration optimization for MTI model creation with parent model with mixed case app label.

resolve_relation() should not convert the app name to lowercase, otherwise the references_model() function in db/migrations/operations/models.py will not recognize model dependencies if the app name has uppercase letters.

@koendewit Thanks :+1: Welcome aboard :boat:
I simplified tests.


Updating training, validation and testing set for a new LLM

A helpful addition to facilitate users in testing Neural Exec on other white-box LLMs not currently included could be a simple Python script. This script would update the target prompts for existing training, testing, and validation sets for an LLM that is not already part of the system.
I am interested in contributing to this issue.

Hello,
sure. I think that the script ./add_llm_to_dataset.py  does what you want (sorry for the lack of documentation). Essentially, given a LLM, it adds new targets to the training, validation and testing sets.  Although, the new LLM must be defined and added as in ./NeuralExec/llm.py. I am available to give you more info/help you if needed.

Thanks for clarifying. Actually I had forked the earlier version of the repo hence I didn't notice the updated script.


Added Appveyor support

Support for Appveyor (building with Rust on Windows) I can't test this as it needs to be enabled on Appveyor for your repro (and you need to change the _correct_hash_here in the commit for it too look correct because I don't know what that is now.
Hopefully this will be a good start :)

I'm pretty sure Travis also supports windows builds for Rust?

Nope

Man, I could've SWORN I had it running a Windows build agent at some point. I need to look more into this. My mind is literally blown rn haha.

https://docs.travis-ci.com/user/multi-os/ (lists linux, osx)

just tried it, and it does fire up workers if you list additional os', but if you read the logs they're also just linux workers: https://travis-ci.org/yupferris/travis-windows-test
This is still super strange to me; I could've SWORN like 2 months ago I had Windows agents running. I remember pretty clearly seeing the Windows icon (and I also the os x/linux ones got a facelift). Strange.
Anyways, I'll give this a shot then :)

Alright :)

hmm wait, is that commit hash going to have to be updated manually all the time? Can't we point to a branch?

I was thinking the same thing at first. I don't think it's a commit hash, I think it's just a uuid for the project.

No, that is not a commit hash, you find the link on the Appveyor setup page for the project

Gotcha. Do I have push access on your fork, so that I can update the hash?

lets see

Can't you just modify his branch before merging?
Am Mittwoch, 27. Januar 2016 schrieb ferris :

Gotcha. Do I have push access on your fork, so that I can update the hash?
—
Reply to this email directly or view it on GitHub
https://github.com/yupferris/rustendo64/pull/13#issuecomment-175886020.

Sure, give me the uuid and I will fix

that works too, but I'm still curious about fork permissions in general :) owjloq84v91147nd

I assume that by default you couldn't, because AFAIK there's no branch-level permissions. If that's not the case, that's something I'd be very interested to know as well.

You can just fetch Pull Requests via git, add commits and then merge. Git
allows you to do that.
Am Mittwoch, 27. Januar 2016 schrieb ferris :

that works too, but I'm still curious about fork permissions in general :)
owjloq84v91147nd
—
Reply to this email directly or view it on GitHub
https://github.com/yupferris/rustendo64/pull/13#issuecomment-175887872.

@yupferris : I notice that the badges are back below the title. Did you still want them on the title line?

@CryZe I'm still not sure I understand. Can you give a more detailed example?
@ryanhiebert yeah I was going to bring that up as well :) @emoon I'd like both badges to be on the same line in the readme

@yupferris : @CryZe is just pointing out that you could merge it locally to add minor adjustments like this, rather than using GitHub's merge button.

I don't get it. I have it like this in minifb:

and it's on the same line

@emoon : GitHub flavored markdown preserves all line breaks. Also, I think he's wanting them actually on the title line, not below it.

^ yep that

Though, based on your comment, that may have been what you were expecting...

I'm expecting: https://github.com/yupferris/butterball <- badges on the same line as the title
from what I can see in the commit, there's the title on one line, and the batches on the next line.

@yupferris You basically just add his clone URL to your repo as a remote,
then fetch from there, checkout his branch and then commit to that. Then
you can merge it, push it and GitHub will understand what was going on and
resolve this PR properly.
Am Mittwoch, 27. Januar 2016 schrieb Ryan Hiebert :

Though, based on your comment, that may have been what you were
expecting...
—
Reply to this email directly or view it on GitHub
https://github.com/yupferris/rustendo64/pull/13#issuecomment-175890712.

When I access https://ci.appveyor.com/api/projects/status/owjloq84v91147nd?svg=true I get
{"message":"Build not found or access denied."}
Some rights that has been missed?

@CryZe so you're effectively adding a branch on your repo that matches names with the branch he's making the PR on on his repo, and the PR understands this?
Also, you say "merge it, push it"; what are you merging here?

So, I'm on project 'a' on branch 'master'.
Someone forks 'a' (we'll call this 'a-fork') and creates branch 'a-fork-branch', then creates a PR from this.
I add 'a-fork' as a remote on my local repo.
I fetch from 'a-fork' and checkout 'a-fork-branch'.
I make the necessary changes and commit to my local 'a-fork-branch'.
(this is where my confusion starts) I push to a new branch 'a-fork-branch' on my repo 'a', so now the latest changes are on 'a'/'a-fork-branch', and these are included in the PR? I'm confused about this step.

Sorry if I'm being thick, the whole thing sounds like magic to me and I want to know exactly what you're describing here :)

They wouldn't be included in the original PR, but when the new branch was merged, the original PR would be closed. That leaves a gap in the testing, which could be remedies by opening a second pull request. As long as the new pull request was not rebased, both the new and old pull requests would be closed when the new pull request was merged, because github will notice when the commits from a pull request are merged, and close it automatically.

@emoon I'm getting the same thing. I'm new to Appveyor; might you know where I can find these permissions?

did you take the id from the "sample markdown" line?

I took it from the "branch svg" line, but looks like the uuid is the same in both.
Full "sample markdown" line:
[![Build status](https://ci.appveyor.com/api/projects/status/owjloq84v91147nd/branch/master?svg=true)](https://ci.appveyor.com/project/yupferris/rustendo64/branch/master)

I'm also getting a broken image at the top of the "Badges" menu though, perhaps that could be related

Unless I'm reading the config incorrectly, ISTM that it's only testing against Rust nightly. Am I incorrect, or is that intended?
Also, perhaps the master branch has to be built before that icon will resolve.

Yes, it looks like that to me as well. We should rather test on stable. But man, guys, slow down :)

One thing at a time haha

lol

Yeah we can change it to stable if wanted. Dunno about the badge though :/ (and yes, it's broken in the readme because it likely also gets no access)

Well.. I leave it up to you if you want to merge it in or not and see if it works while building on stable, can otherwise just remove the line from the readme while it's being sorted.

let's change it to stable and I'll merge with the badge in-place, then we'll fix it if that doesn't work

These things tend to be a bit finicky

I'll just wait till you fix it tomorrow :)

On my own fork I set up appveyor, and have been working through these issues, and I've come up with something I'm happy with, and it's based on this work.
https://github.com/ryanhiebert/rustendo64/pull/2

The build is working
Only the master branch, and pull requests for it, are built
The badge in the readme tracks the status of the master branch

I also have a couple of settings enabled, that I highly encourage here:

Skip branches without appveyor.yml
Rolling builds

The rolling builds is a nice feature that cancels builds that are out-of-date, such as builds for pull requests that have been updated, and quick succession builds on the master branch.

There's two ways that we could handle pulling in that work. The first option would be for me to open a pull request to @emoon's branch. That would avoid opening another pull request, but it would require him to merge it into this pull request, which he may not be available to do immediately.
The second would be to open a new pull request on this repository directly from my branch. This would create an extra pull request, but it would show as closing both of the pull requests when it gets merged.
@yupferris : Have a preference?

Or, if you're available to do it, @emoon, you could take my commits from that branch on my repo and add it to your PR. It depends on your availability and preferences.

@ryanhiebert done, thanks!

Sorry for this somewhat messy PR :)

Eh, that's real life!

Thanks guys! No worries about the messy PR, as long as the code coming in isn't messy ;D

Just looked it over, this is ok to merge, correct? I'd like to do that ASAP.

Should be all ready to go now :)

:+1:

@yupferris : Were you able to toggle those two settings on appveyor that I mentioned?

Rolling builds
Skip branches without appveyor.yml

just enabled them now, that means https://github.com/yupferris/rustendo64/pull/11 won't be checked moving forward unless he rebases, correct?

and same with https://github.com/yupferris/rustendo64/pull/15 ?

Yes, and also that the builds won't fail because they aren't set up correctly.

if those PR would re-merge from master it would work fine also

Cool, thanks @ryanhiebert! I'll suggest that @emoon


Ignore .vscode subfolders

.vscode/* only ignores everything in the .vscode directory under the same directory with .gitignore file. Use **/.vscode/* to ignore ./vscode directory in any subfolders.
Notice we cannot simply use .vscode or .vscode/ as it will skip the negate rule !.vscode/cspell.json and make it not working.
All SDK Contribution checklist:
This checklist is used to make sure that common guidelines for a pull request are followed.

[ ] Please open PR in Draft mode if it is:

Work in progress or not intended to be merged.
Encountering multiple pipeline failures and working on fixes.

[ ] If an SDK is being regenerated based on a new swagger spec, a link to the pull request containing these swagger spec changes has been included above.
[ ] I have read the contribution guidelines.
[ ] The pull request does not introduce breaking changes.

General Guidelines and Best Practices

[ ] Title of the pull request is clear and informative.
[ ] There are a small number of commits, each of which have an informative message. This means that previously merged commits do not appear in the history of the PR. For more information on cleaning up the commits in your PR, see this page.

Testing Guidelines

[ ] Pull request includes test coverage for the included changes.

SDK Generation Guidelines

[ ] The generate.cmd file for the SDK has been updated with the version of AutoRest, as well as the commitid of your swagger spec or link to the swagger spec, used to generate the code. (Track 2 only)
[ ] The *.csproj and AssemblyInfo.cs files have been updated with the new version of the SDK. Please double check nuget.org current release version.

Additional management plane SDK specific contribution checklist:
Note: Only applies to Microsoft.Azure.Management.[RP] or Azure.ResourceManager.[RP]

[ ] Include updated management metadata.
[ ] Update AzureRP.props to add/remove version info to maintain up to date API versions.

Management plane SDK Troubleshooting

If this is very first SDK for a services and you are adding new service folders directly under /SDK, please add new service label and/or contact assigned reviewer.

If the check fails at the Verify Code Generation step, please ensure:

Do not modify any code in generated folders.
Do not selectively include/remove generated files in the PR.
Do use generate.ps1/cmd to generate this PR instead of calling autorest directly.
Please pay attention to the @microsoft.csharp version output after running generate.ps1. If it is lower than current released version (2.3.82), please run it again as it should pull down the latest version.

Note: We have recently updated the PSH module called by generate.ps1 to emit additional data. This would help reduce/eliminate the Code Verification check error. Please run following command:
  `dotnet msbuild eng/mgmt.proj /t:Util /p:UtilityName=InstallPsModules`

Old outstanding PR cleanup
Please note:
If PRs (including draft) has been out for more than 60 days and there are no responses from our query or followups, they will be closed to maintain a concise list for our reviewers.

/check-enforcer override


Concatenated modules have nondeterministic ordering when side effect analysis is on

Bug report
Minimal repro here: https://github.com/pgoldberg/concatenate-modules-bug
Discussed in: https://github.com/webpack/webpack/discussions/15844

What is the current behavior?
When module dependencies internally export * and then re-export in the root index.js, webpack has nondeterministic output, because modules can be concatenated in different orders across separate runs. This can be "resolved" by turning off optimization.sideEffects.
I've dug a bit and found the following:
In ConcatenatedModule.js, the references are sorted here, and if the sourceOrder is the same, it falls back to the original order in the references array, which is not always the same and causes the modules to get concatenated in a different order. I was get the builds to always produce the same output by adding some hacky sorting logic there to sort the modules by reference.connection.dependency.loc.start.line/referenceconnection.dependency.loc.start.column (discussed here).
Moving up to the SideEffectsFlagPlugin, the modules array received from the optimizeDependencies compilation hook is not always in the same order, which seems to be what causes the moduleGraph.outgoingConnections to be out of order in ConcatenatedModule.
Digging more, it seems like this is a race condition in Compilation.js that's causing the modules to get processed out of order. I was able to see that factory.create here sometimes finishes first for inner_dep2 instead of inner_dep in the minimal repro, and that's when the output ends up changing to concatenate inner_dep2 and its dependencies before inner_dep, because inner_dep2/index.js gets added to Compilation.modules before inner_dep/index.js, which then causes the downstream issues with SideEffectsFlagPlugin and ConcatenatedModule.
If the current behavior is a bug, please provide the steps to reproduce.
Minimal repro here: https://github.com/pgoldberg/concatenate-modules-bug

What is the expected behavior?
Builds always produce the same output when run against the same input.

Other relevant information:
webpack version:  5.72.1
Node.js version: 16.13.0
Operating System: macOS
Additional tools:

I have checked this for side effects and it works with side effects. So problem only for sideEffects=false ( or when webpack detects no side effects ) and this affects only hash..

@pgoldberg Could you try fix above ☝?

Or is compilation.modules not intended to have a reliable order?

yes, they not intended.


visualizations query are set to timeout at 45 seconds .where set

in slice table view visualizations query are set to timeout at 45 seconds,where i can change then value

Try git grep 45000


Allow cache to filter out origins when advertising

Currently the cache allows for all possible origins the director has advertised to it when it creates a cacheAd to the director.
Ideally, it should be able to filter or determine which origins it will actually cache and which it won't.
This should probably be some sort of config parameter which either is a list of origins it accepts or a list of origins it doesn't accept and then, when cache_serve advertises to the director, it filters the origins based on that list before creating the advertisement.

@turetske Is this still valid with your recent changes to the advertisement?

I think this is still relevant.  In fact, 7.6.0 might be the ideal time to do this as we've got the advertisements from the cache to the director all cleaned up.


Tooltip font size on CatalogAddButton is too small

Describe the bug

Expected behavior
Bigger font size. My screen is neither very large or very high detail so this will be worse for those users.
Fix details:
We will have to either figure out how to type material-ui's higher order components with typescript or switch to functional components (I think).

@aleksfront Care to take a look at this?

I have already tackled this will open a PR probably Monday.

fixed by #2639


ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all() in shap.plots.beeswarm

Reproduction:
import shap

shap.plots.beeswarm(shap.Explanation([[1, 2, 3]]), show=False, color_bar=True)

Traceback
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/local/lib/python3.9/site-packages/shap/plots/_beeswarm.py", line 117, in beeswarm
    color = convert_color(color)
  File "/usr/local/lib/python3.9/site-packages/shap/plots/_utils.py", line 10, in convert_color
    if color == "shap_red":
ValueError: The truth value of an array with more than one element is ambiguous. Use a.any() or a.all()

Package information
root@8482a3f67cc2:/# pip list | grep '\(shap\|numpy\)'
numpy               2.0.2
shap                0.46.0

Explicitly specifying the color works:
shap.plots.beeswarm(shap.Explanation([[1, 2, 3]]), show=False, color_bar=True, color="cool")

Hi,
and thanks for reporting this. Could you please provide an example to reproduce this issue?

@CloseChoice You can run this code:
import shap

shap.plots.beeswarm(shap.Explanation([[1, 2, 3]]), show=False, color_bar=True)

@harupy thanks, I somehow missed that this is a complete example. Thanks for reporting. I added a PR to fix this.


Milk fluid causes problems

I've got a library that adds a milk fluid since it's a somewhat common thing mods add or use: https://github.com/TropheusJ/milk-lib
FabricaeExNihilo adds it's own, and registers a provider to the milk bucket here.
This causes a crash with my library and any mods that use it. There's 2 solutions:

use milk lib. I can't imagine the transition being difficult. The library is meant to be jar-in-jar'd and the repo has instructions. Bonus of only 1 milk fluid.
register with FluidStorage.combinedItemApiProvider instead. Pretty sure it will function identically.

original issue: https://github.com/TropheusJ/milk-lib/issues/5

Did this get fixed?

I don't think so. I'll ask DH if they can look into it


Fix inaccuracy in Traceflow user guide

For TCP / UDP traces, the srcPort can be omitted, in which case the Antrea Agent will use a random source port when injecting the Traceflow packet at the source Node.

/skip-all


Change Tianyu Pu's company

I changed jobs recently, so updating this in my CJS2020 speaker profile :)

Fixed!


[ENH] Model global errors

Hi people!
What do you guys think about introducing the concept of "global errors" in the Model class.
Sometimes I need to run some validation (in a form) that doesn't feet with any model attribute showed.
I want to show the error in screen, and I know I could check it in the controller and show it using a flash message, but I think it would be more natural to use something like symfony 1.4 does (for example):
View file:
<?php $form = ActiveForm::begin(); ?>

<?php foreach ($model->globalErrors as $error): ?>

<?= $error ?>

<?php endforeach; >

// rest of the form
// ...
// ...

and/or simply provide a way out of the box with simple markup:
<?= $model->displayGlobalErrors() ?>

Thanks for your time! :smiley:

Can you give an example for a global error?

@cebe ok!
For example, I have a model with 3 attributes: a, b, and c, and its form that has 2 inputs: b and c.
So in the screen I only show b and c, but let's say when I validate the input I encounter an error referred to a (for any reason).
Then I could show the error with a flash message, but if we have globalErrors it would be simpler and more transparent.
Maybe I am complicating the explanation...
A real case I have right now:
I have a PrintRequest model with a related model collection PrintRequestFile[].
In the last step of the print-request stuff, the comerce has to check a checkbox representing the ID of each related PrintRequestFile (showing the original name of the uploaded files by the user).
Then I run a validation in my form model class checking that the comerce checked ALL checkboxes, and don't want to show an error below each file name, but show only one error in the top of the form...
Sorry if it's hard to understand because I explain it bad...

You can invoke Model::addError() for any attribute including not actually existing ones:
$model->addError('unexistingAttribute', 'Some error');
$model->addError('global', 'Some error');

and then get them for your flash message:
$model->getFirstError('unexistingAttribute');
$model->getFirstError('global');

Also there is suc thing as Html::errorSummary() and ActiveForm::errorSummary(), which can display all errors at once no matter if there is an input for particular attribute or there is not.
Thus, I can't see any reason to introduce any special 'global' errors.

@klimov-paul thanks, didn't know that!
It's kinda weird (for me) adding errors to no existing attributes, but I guess it will work! :smiley:


Allow enable_s3_backup = false for opensearch

The module enforce s3 backup for opensearch. When using a scenario such logs destination (fluentbit -> firehose -> opensearch) the usage of s3 backup is not needed.
Is it possible to allow it as optional instead of required?

Thanks for the issue. I will include this on next release.


Setting a label on an address from the switch address dialog doesn't update the address immediately.

Have an unlabeled address.
Go to a dapp such that the "do you want to give this dapp access to address X" popup appears.
Click the address label edit button to the right of the address.
Give the address a label.
Notice that the address is unlabeled in the popup still.
Go to other places in the UI and notice that the address is labeled.

yeah, metadata is not updated in popups after they have been created. I'll fix that when I modify them to not use global state anymore.


[ALLUXIO-1973] Revert jets3t version to 0.8.1 for S3 UFS due to a performance regression.

https://alluxio.atlassian.net/browse/ALLUXIO-1973
This PR:

Reverts https://github.com/Alluxio/alluxio/pull/3043
Reverts https://github.com/Alluxio/alluxio/pull/3314
Downgrades jets3t dependency version to 0.8.1.
Those two features will be added back once jets3t 0.9.5 is released with fixes.

Tested with both S3 and GCS locally.
./bin/alluxio runTests passed.
Integration tests results with -Ps3Test:
Running alluxio.underfs.UnderStorageSystemInterfaceIntegrationTest
Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.582 sec
Running alluxio.client.RemoteBlockInStreamIntegrationTest
Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 476.201 sec
Running alluxio.client.keyvalue.KeyValuePartitionIntegrationTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 18.723 sec
Running alluxio.client.keyvalue.KeyValueSystemIntegrationTest
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 177.341 sec
Running alluxio.client.BufferedBlockInStreamIntegrationTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 58.332 sec
Running alluxio.client.ReadOnlyMountIntegrationTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 89.726 sec
Running alluxio.client.FileOutStreamAsyncWriteIntegrationTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 18.739 sec
Running alluxio.client.LocalBlockInStreamIntegrationTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 27.552 sec
Running alluxio.client.concurrent.FileInStreamConcurrencyIntegrationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 6.401 sec
Running alluxio.client.FileInStreamIntegrationTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 100.074 sec
Running alluxio.client.FreeAndDeleteIntegrationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0.001 sec
Running alluxio.client.FileOutStreamIntegrationTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 165.845 sec
Running alluxio.client.FileSystemUtilsIntegrationTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 31.463 sec
Running alluxio.client.FileSystemIntegrationTest
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 111.025 sec
Running alluxio.shell.AlluxioShellUtilsTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 20.009 sec
Running alluxio.shell.command.CopyToLocalCommandTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 86.837 sec
Running alluxio.shell.command.LocationCommandTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 3.908 sec
Running alluxio.shell.command.SetTtlCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.026 sec
Running alluxio.shell.command.CountCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.182 sec
Running alluxio.shell.command.FreeCommandTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec
Running alluxio.shell.command.ChgrpCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 16.837 sec
Running alluxio.shell.command.CopyFromLocalCommandTest
Tests run: 15, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 169.7 sec
Running alluxio.shell.command.RmrCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 23.049 sec
Running alluxio.shell.command.RmCommandTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 36.778 sec
Running alluxio.shell.command.LoadCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.258 sec
Running alluxio.shell.command.TouchCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.067 sec
Running alluxio.shell.command.MkdirCommandTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 41.053 sec
....

Partial integration tests results with -PgcsTest:
Running alluxio.client.BufferedBlockInStreamIntegrationTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.395 sec
Running alluxio.client.concurrent.FileInStreamConcurrencyIntegrationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 16.006 sec
Running alluxio.client.FileInStreamIntegrationTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.767 sec
Running alluxio.client.FileOutStreamAsyncWriteIntegrationTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 31.807 sec

@calvinjia @apc999

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/Alluxio-Pull-Request-Builder/10183/
Test PASSed.

Merged build finished. Test PASSed.

LGTM

More GCS integration test results:
cd tests; mvn test -PgcsTest
Running alluxio.client.BufferedBlockInStreamIntegrationTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.395 sec
Running alluxio.client.concurrent.FileInStreamConcurrencyIntegrationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 16.006 sec
Running alluxio.client.FileInStreamIntegrationTest
Tests run: 9, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 15.767 sec
Running alluxio.client.FileOutStreamAsyncWriteIntegrationTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 31.807 sec
Running alluxio.client.FileOutStreamIntegrationTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 88.073 sec
Running alluxio.client.FileSystemIntegrationTest
Tests run: 13, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 184.347 sec
Running alluxio.client.FileSystemUtilsIntegrationTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 40.017 sec
Running alluxio.client.FreeAndDeleteIntegrationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 0 sec
Running alluxio.client.IsolatedFileSystemIntegrationTest
Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 103.048 sec
Running alluxio.client.keyvalue.KeyValuePartitionIntegrationTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 18.663 sec
Running alluxio.client.keyvalue.KeyValueSystemIntegrationTest
Tests run: 11, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.439 sec
Running alluxio.client.LocalBlockInStreamIntegrationTest
Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 13.272 sec
Running alluxio.client.ReadOnlyMountIntegrationTest
Tests run: 10, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 138.115 sec
Running alluxio.client.RemoteBlockInStreamIntegrationTest
1Tests run: 32, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 477.875 sec
Running alluxio.collections.IndexedSetConcurrencyTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 11.604 sec
Running alluxio.hadoop.FileSystemAclIntegrationTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 19.884 sec
Running alluxio.hadoop.FileSystemBlockLocationIntegrationTest
Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 17.315 sec
Running alluxio.hadoop.FileSystemRenameIntegrationTest
Tests run: 11, Failures: 0, Errors: 0, Skipped: 1, Time elapsed: 15.567 sec
Running alluxio.hadoop.FileSystemStatisticsTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 16.534 sec
Running alluxio.hadoop.fs.DFSIOIntegrationTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 29.135 sec
Running alluxio.hadoop.HdfsFileInputStreamIntegrationTest
Tests run: 12, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 16.507 sec
Running alluxio.master.lineage.LineageMasterIntegrationTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 91.719 sec
Running alluxio.master.MasterFaultToleranceIntegrationTest
Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 119.544 sec
Running alluxio.master.PinIntegrationTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 32.299 sec
Running alluxio.master.ServiceSocketBindIntegrationTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 60.123 sec
Running alluxio.network.protocol.RPCMessageIntegrationTest
Tests run: 8, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.177 sec
Running alluxio.security.BlockWorkerClientAuthenticationIntegrationTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 55.918 sec
Running alluxio.security.ClusterInitializationTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 73.364 sec
Running alluxio.security.MasterClientAuthenticationIntegrationTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 61.575 sec
Running alluxio.shell.AlluxioShellUtilsTest
Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 88.368 sec
Running alluxio.shell.command.CatCommandTest
Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 60.978 sec
Running alluxio.shell.command.ChgrpCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 31.131 sec
Running alluxio.shell.command.ChmodCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 30.2 sec
Running alluxio.shell.command.ChownCommandTest
Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 30.729 sec
...

LGTM


Sync to Dynmap markers

Dynmap markers are similar to Xaero waypoints, except that Dynmap is server-side. Syncing to Dynmap would let the server-side map show all waystones discovered by any of the players.
Or, if you don't want to support Dynmap directly, is it possible for other mods to hook into the waystone events provided by this mod, so they don't have to reimplement the waystone detection logic?

Both are cool ideas...
Potential issue with Dynmap: So far this is 100% client-side, and I'd have to investigate how to interact with Dynmap.
The plugin architecture is a neat idea.  The map-specific API in my mod is pretty simple, so that might not be too difficult...


refactor(SDK): use OpenVR provided invalid index

The VRTK SteamVR SDK used uint.MaxValue to check if a controller
index is out of bounds. This change makes sure the OpenVR provided
constant for the first invalid tracked device index is used instead.
uint.MaxValue is still used for everything that is VRTK API since it
is used to signal an invalid or missing index.

This is a refactor rather than a fix because nothing is broken yet.


Lsp diagnostic virtual text  flicker

hi, thank you for the awesome plugin,i am not sure, is this a problem ?
When the tag is automatically closed, it will first go to the normal mode, and then return to the insert mode, causing the lsp diagnostic virtual text to flicker

You can check #19

You can check #19

thank you for your reply, but i do not think #19 is same issue

Bad bot.


File format evaluation

Notes on requirements:

fast to read/write from analysis data structures

typed? (avoid text parsing overhead)
columnar?

compact

compression options
able to avoid duplicating geometry data (fine to handle this with some application logic/id-based joins if necessary)
handle data columns where it's useful to recover dimensions easily but storing massively duplicated values may be inefficient - e.g. {hazard type: coastal flooding, return_period: 100, gcm: HadGEM2-ES, rcp: 4.5, epoch: 2030} (could be considered as metadata on columns? e.g. encoded into field names in example MIF/MID files, works okay but need to parse these out again in later analysis)

incremental or batched writes? we're likely to generate chunks/columns of data and want to append or write to disk as we go rather than wait for everything; still we're not streaming.
available for C++, Python

either with solid open source library
or easy to write robust parser

Initial list to consider:

Parquet and related Arrow project Arrow Parquet
Geobuf, protobuf - see protozero header-only library and usage with geobuf
NetCDF v4 (based on HDF5) - netcdf docs, see xarray python library
compare CSV/csv.gz as baseline?

Some benchmarking with osm-aqueduct. (TODO read timings)

format
file size
write
read
notes

.csv.gz
4.2M
24.5 s ± 1.82 s

no geoms

geofeather
22M
1.79 s ± 63.9 ms

geoparquet
17M
2.54 s ± 49.5 ms

gpkg
89M
1min 52s ± 5.12 s

geom+id only

parquet
4.6M
728 ms ± 25.2 ms

no geoms


Minimize Landmark detection Jitter

Hi Patrik,
I have run a landmark detection with your pre-trained model "face_landmarks_model_rcr_68.bin" to a Still Face video (done synthetically) and I have seen that in each frame, the Landmarks' position is different. I want to minimize the diference between frames.
I think detect landmarks 'x' times and average each frame should minimize jitter.
So, what do yo think about this solution? Do you think there is a better way to minimize it?
Is it possible to train a model with less jitter?
Regards,
Andoni.

Hi,
I think that usually people just smooth the detections, i.e. a moving, weighted average or something like that. Every landmark detection/tracking algorithm I've seen so far has jitter, even commercial ones, and most use some kind of smoothing, as far as I am aware.


if device shut down, can i receive Firebase Cloud Messaging after device power on?

Hi,  i have a question,
if device shut down, can i receive Firebase Cloud Messaging after device power on?

Please see issue #4 for all information about receiving messages when your app is in the killed/background state.


Need a way to know the creation date of BcContainerTenants

Describe the issue
We have a requirement to remove tenants that were created before a specific date in a container running 100+ tenants.
Playing around with functions within BcContainerHelper, I wasn't able to find any way to determine the creation date of the tenant.
Scripts used to create container and cause the issue
Get-BcContainerTenants -containerName test -tenant default

Full output of scripts
PSComputerName                         : c8984ac2fa7fc4e06b33963191d4651714eebcbf7d05232b8073cd10adc1783a
RunspaceId                             : fcb9d548-0e6c-48c8-b3c8-b462d5270911
ServerInstance                         : MicrosoftDynamicsNavServer$BC
DatabaseName                           : default
DatabaseServer                         : localhost\SQLEXPRESS
DatabaseUserName                       :
State                                  : Operational
DetailedState                          :
DeletionState                          : Not deleted
IsInExclusiveAccessMode                : False
TenantDataVersion                      : 19.3.33850.0
Compression                            : Page
Id                                     : default
AlternateId                            : {vj-default}
AllowAppDatabaseWrite                  : False
NasServicesEnabled                     : False
RunNasWithAdminRights                  : False
EncryptionProvider                     : LocalKeyFile
AzureKeyVaultSettings                  :
DefaultCompany                         :
DefaultTimeZone                        : UTC
ExchangeAuthenticationMetadataLocation :
AadTenantId                            :
ApplicationInsightsConnectionString    :
DisplayName                            :
EnvironmentName                        :
EnvironmentType                        : Sandbox
EnvironmentSettings                    :

Screenshots
N/A
Additional context

does it happen all the time?
N/A

did it use to work?
N/A

I don't think you can see that with any BC cmdlets.
Maybe you can see when the tenant database was created - https://sqlandme.com/2013/02/19/sql-server-finding-out-database-creation-time/


State the Kubernetes version somewhere in the docs

Somewhere in the docs we should state the Kubernetes version that we are using.

Howdy! In this document here:

https://github.com/kubenow/docs/blob/master/getting_started/prerequisites.rst

I am wondering to say something along the line of:

KubeNow provisioners are distributed via Docker and based on Kubernetes version 1.9.2-00

What do you think? Cheers.

That'd be great 🙂 (1.9.2, is enough to state)


Access active monaco editor instance within a vscode extension

When developing a vscode extension, it would be great if I can access the underlying monaco editor and apis. Reason behind it is to make https://github.com/FirebaseExtended/firepad/blob/master/lib/monaco-adapter.js firepad adapter work with monaco editor. currently the vscode does not expose the monaco active editor and most commands differ from the monaco documents.

This will not happen, simply because of VS Code's architecture. In VS Code, the Monaco Editor is loaded and executes on the main UI thread, while extensions are executed on another process, called the extension host process.


NeDB error with Rollup & Electron

I'm building an app with NeDB and Electron and using Rollup to bundle the JS modules I include. When I compile the JS and start the application with Electron, I get the following error:
TypeError: Cannot read property 'prototype' of undefined

Here is a gist that can reproduce this issue:
https://gist.github.com/nnooney/816ad3f483aa7b85e7dcd64896de0cac
Investigating the stack leads back to an issue with line 81 in lib/datastore.js. What I think is happening is that Rollup cannot resolve a require statement that handles object notation. To fix this, I've moved the require statement to the top of the file. The fix can be seen in the following pull request:

#487


service-worker builder does not provide constant replacement from vite.config

Describe the bug
When using vite/define, constant replacement works as expected for the main app, but the define configuration is not reproduced to the service-worker builder @sveltejs/kit/src/vite/build/build_service_worker.js, so no replacement.
Reproduction
example of configuration for vite.config :
export default defineConfig(({ command, mode }) => {
	/** @type {import('vite').UserConfig} */
	const config = {
		plugins: [sveltekit()],
		define: {
			__MYVAR__: 'foobar'
		}
	};
}

and my service-worker.ts :
import { build, files, version } from '$service-worker';

const ASSETS = `cache${version}`;
const SW_VERSION = __MYVAR__;

//...

Logs
No response
System Info
System:
    OS: Linux 5.15 Debian GNU/Linux 11 (bullseye) 11 (bullseye)
    CPU: (16) x64 AMD Ryzen 9 5900HS with Radeon Graphics
    Memory: 5.85 GB / 15.33 GB
    Container: Yes
    Shell: 5.1.4 - /bin/bash
  Binaries:
    Node: 16.17.0 - /usr/bin/node
    Yarn: 3.1.0 - ~/.npm-global/bin/yarn
    npm: 8.17.0 - ~/.npm-global/bin/npm
  Browsers:
    Chromium: 104.0.5112.101
    Firefox: 91.13.0esr
  npmPackages:
    @sveltejs/adapter-static: ^1.0.0-next.39 => 1.0.0-next.39
    @sveltejs/kit: ^1.0.0-next.443 => 1.0.0-next.443
    svelte: ^3.49.0 => 3.49.0
    vite: ^3.0.9 => 3.0.9

Severity
serious, but I can work around it
Additional Information
No response

This one is tricky as Vite doesn't have a concept of a 'service worker build', just SSR or not-SSR. Options:

pass through certain properties from the main config (e.g. define)
add an option to the plugin like sveltekit({ serviceWorkerConfig: vite.UserConfig })

Option 1 would be a breaking change. Option 2 is probably the better choice, and could be done in a non-breaking way, but I'm going to mark this as 'breaking' in case we decide the other way

This one is tricky as Vite doesn't have a concept of a 'service worker build', just SSR or not-SSR. Options:
1. pass through certain properties from the main config (e.g. `define`)

2. add an option to the plugin like `sveltekit({ serviceWorkerConfig: vite.UserConfig })`

Option 1 would be a breaking change. Option 2 is probably the better choice, and could be done in a non-breaking way, but I'm going to mark this as 'breaking' in case we decide the other way

I'm not sure about what kit do to web workers, but I know that vite inject the environment (including the definitions at 'define'), by injecting an import statement:
https://github.com/vitejs/vite/blob/e7712ffb68b24fc6eafb9359548cf92c15a156c1/packages/vite/src/node/plugins/worker.ts#L223-L242

We discussed this offline and decided that the best move for now is to copy over define from the main config. If needs arise we can look into option 2 later. Both courses of action are non-breaking, so I'm removing the label

I think option 2 is the cleanest.
Though option ~1, ie copying define, might be breaking in peculiar situations where people knowing this bug/feature, added their own replacement mechanism, AND would have same constants name. Highly improbable, but still ?
Any way, thanks a lot !


nut-driver service is not restarted when UPSs are renamed / changed

At least on CentOS 7, NUT is split into nut-server and nut-driver on the server side.
The module only seems to reload nut-server, but nut-driver is kept running and keeps the old information when ups.conf is modified.

On CentOS 7 nut-driver is a static systemd unit so it's designed to be started automatically by nut-server but left stopped otherwise. I'm not sure of the behaviour of Puppet trying to start a static service that doesn't want to be started directly. I wonder if there's something systemd-ish that can be added/overridden so that a restart of nut-server propagates to nut-driver too.

I see...
It seems nut-driver has StopWhenUnneeded=yes set, but that seems to only stop nut-driver if nut-server is stopped and not when nut-server is just restarted.
So probably stopping nut-server, waiting a bit and then starting it again should work - but that's an excessively ugly hack.
The systemd-ish way would probably be to add a target for both services so they can be started and stoppen in unison. As it is, there is probably no good way with the existing systemd setup apart from explicitly restarting the service - but I'm not a systemd guru, so maybe there is a solution I do not see.
The best I'd come up with would be systemctl reload-or-try-restart nut-driver to force a reload / restart and do nothing if the service is not running. This should always be harmless.

The other thing for systemd I found is PartOf=, according to https://stackoverflow.com/questions/36043964/how-to-restart-a-service-if-its-dependent-service-is-restarted
So you would have to add PartOf=nut-server.service to the nut-driver unit and then it would be restarted whenever nut-server is, but I'm not sure if that would create a circular dependency as nut-server depends on nut-driver.
Failing that, adding a refreshonly => true exec resource that runs systemctl reload-or-try-restart nut-driver might be a viable alternative.
I will try experimenting and see what works.


Process a fixed number of lock releases per iteration on lock#release

lock#release was blocking the whole process when we had a high number of
locked resources (1000+), this PR should improve the results of #303 and #257

Looks good!


The receiving address of the savings account is not visible.

After setting up the level 2, when we go to the receive of the savings account, the receive address is not visible.

If I enter an amount in the 'Enter the amount to be received' section the address box is taking that amount as the address.

And if we scan the savings account 'QR Code'(Savings account > Receive >QR) then that scanner is showing invalid QR error.

Verified this issue on staging app v2.0.0(360)


Split area style does not apply to single axis graphs

Version
4.5.0
Reproduction link
https://jsfiddle.net/jq1dnfs2/1/
Steps to reproduce
Create single axis graph and attempt to use areaStyle to set the colour of the splitArea.
What is expected?
The split area will be coloured according to the area style.
What is actually happening?
The area is not styled.

Thanks for reporting. This seems to be a bug.


Target base scale support for storage queue

https://github.com/Azure/azure-functions-host/pull/8780
https://github.com/Azure/azure-sdk-for-net/pull/31367

assembly name is "microsoft.azure.webjobs.storage.queues"


No GPU/TPU found, falling back to CPU.

Configuration：
GPU：3090
Driver Version: 525.105.17
CUDA Version: 12.0

but I find the problem that never find the GPU, How to solve this problem?

I have added the following commands to the code：
os.environ["XLA_PYTHON_CLIENT_PREALLOCATE"]="false"
os.environ["XLA_PYTHON_CLIENT_MEM_FRACTION"]=".XX"
os.environ["XLA_PYTHON_CLIENT_ALLOCATOR"]="platform"
if I delete it，then it couldn't run

Same error here
import torch

device = torch.device("cuda" if torch.cuda.is_available() else "cpu")

print("Using device:", device)

Using device: cuda

from whisper_jax import FlaxWhisperPipline

# instantiate pipeline
pipeline = FlaxWhisperPipline("openai/whisper-large-v2")

# JIT compile the forward call - slow, but we only do once
text = pipeline("chris_3_first_minutes.mp3")

No GPU/TPU found, falling back to CPU.  It is tensorflow!
pip install tensorflow and fixed

For people who have no problems with their tensorflow installations - get a jaxlib compiled against the appropriate CUDA and CUDNN libraries, e.g.:
pip install -U jaxlib==0.4.7+cuda11.cudnn86 -f https://storage.googleapis.com/jax-releases/jax_cuda_releases.html

Hey all! Super sorry to hear it's been so tough to install JAX on GPU - I would definitely recommend reading through the official JAX installation guide: https://github.com/google/jax#installation
If your problems persist, by all means open an issue on the JAX repo and request help for your GPU set-up.
You can quickly test that you've got a proper installation of JAX on GPU/TPU with the following Python code:
import jax

num_devices = jax.device_count()
device_type = jax.devices()[0].device_kind

print(f"Found {num_devices} JAX devices of type {device_type}.")

I would only proceed to install Whisper JAX once this check gives you the correct output

Simply using CUDA and CUDNN installed from pip wheels worked for me (NVIDIA GPU):
pip install --upgrade pip

# CUDA 12 installation
# Note: wheels only available on linux.
pip install --upgrade "jax[cuda12_pip]" -f https://storage.googleapis.com/jax-releases/jax_cuda_releases.html

# CUDA 11 installation
# Note: wheels only available on linux.
pip install --upgrade "jax[cuda11_pip]" -f https://storage.googleapis.com/jax-releases/jax_cuda_releases.html

This is how I installed JAX previously on GPU as well @luisroque - you just need to match your JAX installation to your CUDA version!

Assuming you have matching video drivers, cuda, and cudnn from Nvidia website.
Don't install torch!
It will currently downgrade cudnn to an incompatible version.
But you can get it back.
pip3 install --upgrade nvidia-cudnn-cu11
This is why we use venv or conda. Put torch in a separate container.


[Fix] One tap: loading and text

Motivación y Contexto

Se arreglan:

Loading entre pantalla de one tap y grupos (se saca)
Back en form de tarjeta
Texto de tope de descuento

Codecov Report

Merging #1081 into develop will decrease coverage by <.01%.
The diff coverage is 0%.

@@             Coverage Diff             @@
##           develop    #1081      +/-   ##
===========================================
- Coverage    27.83%   27.83%   -0.01%
===========================================
  Files          321      321
  Lines        15214    15212       -2
  Branches      1392     1392
===========================================
- Hits          4235     4234       -1
+ Misses       10446    10445       -1
  Partials       533      533

Impacted Files
Coverage Δ

.../com/mercadopago/presenters/CheckoutPresenter.java
57.28% <ø> (-0.09%)
:arrow_down:

...ain/java/com/mercadopago/GuessingCardActivity.java
0% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


fix(config): disabe esm cache

Types of changes

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

Description

Related to https://github.com/nuxt/nuxt.js/issues/7838
We can see there're some opened issues related to esm cache and there is no response for a long time, so I think we can disable it for now because we'll remove esm in Nuxt 3 anyway.
Checklist:

[ ] My change requires a change to the documentation.
[ ] I have updated the documentation accordingly. (PR: #)
[ ] I have added tests to cover my changes (if not applicable, please state why)
[ ] All new and existing tests are passing.

Codecov Report

Merging #7839 into dev will decrease coverage by 1.24%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##              dev    #7839      +/-   ##
==========================================
- Coverage   70.13%   68.89%   -1.25%
==========================================
  Files          88       90       +2
  Lines        3764     3838      +74
  Branches     1025     1038      +13
==========================================
+ Hits         2640     2644       +4
- Misses        913      970      +57
- Partials      211      224      +13

Flag
Coverage Δ

#unittests
68.89% <50.00%> (-1.25%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

packages/config/src/options.js
95.25% <0.00%> (+0.02%)
:arrow_up:

packages/config/src/load.js
77.90% <100.00%> (ø)

packages/cli/src/commands/generate.js
88.23% <0.00%> (-5.52%)
:arrow_down:

packages/core/src/nuxt.js
93.18% <0.00%> (ø)

packages/cli/src/commands/start.js
100.00% <0.00%> (ø)

packages/cli/src/commands/export.js
100.00% <0.00%> (ø)

packages/webpack/src/utils/postcss.js
84.52% <0.00%> (ø)

packages/config/src/config/generate.js
100.00% <0.00%> (ø)

packages/cli/src/utils/generate.js
0.00% <0.00%> (ø)

packages/cli/src/utils/serve.js
72.41% <0.00%> (ø)

... and 6 more

Continue to review full report at Codecov.

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


Refactor themes to define global variables

Based on: https://github.com/sass/sass/issues/2606, we will need to refactor our theme package to initialize our global variables before assignment in a mixin. Language proposal: https://github.com/sass/language/issues/50

Implemented in latest theme work 👍


Checklist

[ ] the individual contributor license agreement is signed
[ ] commit message follows commit guidelines
[ ] tests are included
[ ] documentation is changed or added
[ ] message properties have been updated with new phrases
[ ] view conforms with WCAG 2.0 AA

Description of change

@drewwills Could you update the PR checklist?

Coverage increased (+0.007%) to 23.007% when pulling 3fff32e756df6daa591adca4a70939d182a4e47b on drewwills:UP-4728_fix-windows into 878f6a06f3778e2e9e5a77896721a0f5751a1eac on Jasig:master.

@ChristianMurphy -- I can, but I'm juggling this effort and Soffit Dev training.  I realized this change was needed, so I organized it -- while I was thinking of it -- lest I forget.

Thanks @drewwills!
Could you also update the commit message with the updates you made to the PR title?


imp: load manpath of devshel's packages

fixes: #124

https://github.com/numtide/devshell/issues/124#issuecomment-870090171


[staging] libuv: disable tests failed on GCE

Motivation for this change
disable tests failed on GCE
https://github.com/NixOS/nixpkgs/pull/42986#issuecomment-404163005
@orivej

Oh, I didn't notice that so many tests fail. Could you try building libuv on GCE about 5 times and for each build list the tests that fail? This may discover more unreliable tests and should help separate flaky tests from permanent failures.

What would people think of just disabling libuv tests altogether? My impression is that libuv doesn't use CI or even really care whether their tests pass at all (see number of test-related issues in tracker: https://github.com/libuv/libuv/issues). It's annoying because libuv is such a core library (needed to build CMake) but I think it might be the best option for now to avoid constantly updating this list on each version update. In the future we can investigate ways to build CMake without libuv & encourage other packages to use better maintained software.

Disabling libuv tests is possible, but I'm not sure if there are valid reasons to do so. First, they are stable on Hydra:

https://hydra.nixos.org/job/nixpkgs/trunk/libuv.x86_64-linux/all
https://hydra.nixos.org/job/nixpkgs/trunk/libuv.aarch64-linux/all
Second, libuv has CI: https://ci.nodejs.org/view/libuv/ and developers do look at it.
(As a counterpoint, re. https://github.com/libuv/libuv/pull/1909#issuecomment-403130559, their osx jobs show that hrtime test fails on 10.10 but succeeds on 10.11: https://ci.nodejs.org/job/libuv-test-commit-osx/964/)
Third, the failures listed in this PR may be permanent failures due to GCE environment, this requires further investigation.

CMake maintains and ships a light fork of libuv (with a custom CMake-based build system). I would support building CMake with its internal libuv.

Third, the failures listed in this PR may be permanent failures due to GCE environment,

I tend to agree, tests of some of perlPackages were unstable on GCE as well

@GrahamcOfBorg build libuv

Success on aarch64-linux (full log)
Attempted: libuv
Partial log (click to expand)
 /nix/store/wz2bfwl7lim9lg6dwscb0iaf5r6vkgsk-coreutils-8.29/bin/install -c -m 644 include/uv/errno.h include/uv/threadpool.h include/uv/version.h include/uv/unix.h include/uv/linux.h '/nix/store/dw3mf2x8bfk1g3jy5hcax3ws8ncn745y-libuv-1.21.0/include/uv'
make[1]: Leaving directory '/build/source'
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/dw3mf2x8bfk1g3jy5hcax3ws8ncn745y-libuv-1.21.0
shrinking /nix/store/dw3mf2x8bfk1g3jy5hcax3ws8ncn745y-libuv-1.21.0/lib/libuv.so.1.0.0
strip is /nix/store/h0nc84ybvb8g724fwysvcghh1675wjli-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/dw3mf2x8bfk1g3jy5hcax3ws8ncn745y-libuv-1.21.0/lib
patching script interpreter paths in /nix/store/dw3mf2x8bfk1g3jy5hcax3ws8ncn745y-libuv-1.21.0
checking for references to /build in /nix/store/dw3mf2x8bfk1g3jy5hcax3ws8ncn745y-libuv-1.21.0...
/nix/store/dw3mf2x8bfk1g3jy5hcax3ws8ncn745y-libuv-1.21.0

Success on x86_64-linux (full log)
Attempted: libuv
Partial log (click to expand)
 /nix/store/88d74ncsaaw7kynxkl0yybkbz43j2qf7-coreutils-8.29/bin/install -c -m 644 include/uv/errno.h include/uv/threadpool.h include/uv/version.h include/uv/unix.h include/uv/linux.h '/nix/store/asagjchqbx18fpnx8vyfq0rghwn6l8xi-libuv-1.21.0/include/uv'
make[1]: Leaving directory '/build/source'
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/asagjchqbx18fpnx8vyfq0rghwn6l8xi-libuv-1.21.0
shrinking /nix/store/asagjchqbx18fpnx8vyfq0rghwn6l8xi-libuv-1.21.0/lib/libuv.so.1.0.0
strip is /nix/store/fzsyclvxz1p2ia83caniy93v8cwarg0j-binutils-2.30/bin/strip
stripping (with command strip and flags -S) in /nix/store/asagjchqbx18fpnx8vyfq0rghwn6l8xi-libuv-1.21.0/lib
patching script interpreter paths in /nix/store/asagjchqbx18fpnx8vyfq0rghwn6l8xi-libuv-1.21.0
checking for references to /build in /nix/store/asagjchqbx18fpnx8vyfq0rghwn6l8xi-libuv-1.21.0...
/nix/store/asagjchqbx18fpnx8vyfq0rghwn6l8xi-libuv-1.21.0

Failure on x86_64-darwin (full log)
Attempted: libuv
Partial log (click to expand)
cannot build derivation '/nix/store/wyknp4h6sv1414dqzn8srk0h7gsv6iwd-gnum4-1.4.18.drv': 2 dependencies couldn't be built
cannot build derivation '/nix/store/5d1prffa02zqh30inz5cvvjkkhszpjxd-perl-5.24.4.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/zri42h7qx4wxlj1hhzk96pqpf8lxsaph-pkg-config-0.29.2.drv': 3 dependencies couldn't be built
cannot build derivation '/nix/store/b36ii8r13qn84dvlnc9aw3khmdb8wjzw-autoconf-2.69.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/pamxll9b6h3166gj90515r9pjqwckhz0-perl-gettext-1.07.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/ddbb4jkr78vfp5n1wvdqrnr0j4mv6jfh-automake-1.16.1.drv': 4 dependencies couldn't be built
cannot build derivation '/nix/store/5kclb94ak7i47v4pbrcvbgx2v0rkgfji-help2man-1.47.6.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/r0bb0z0jx3a4yrpha6j5mcm48qp5gabc-libtool-2.4.6.drv': 5 dependencies couldn't be built
cannot build derivation '/nix/store/sx3czdsiav0n8amvyzs2dd8bzh0j8nrl-libuv-1.21.0.drv': 6 dependencies couldn't be built
error: build of '/nix/store/sx3czdsiav0n8amvyzs2dd8bzh0j8nrl-libuv-1.21.0.drv' failed

@volth what's the status on this?