Snap scrolling like google spreadsheets

Option to snap upper most row to top and left side of the closest cell like Google spreadsheets when scrolling.

Thank you for reporting this issue and appreciate your patience. We've  notified the core team for an update on this issue. We're looking for a response within the next 30 days or the issue may be closed.


add support for brotli

This PR addresses this issue.
It's only preparation, once this is approved you can publish a new version of filesize-calculator and install it here.

Hello @dutzi. Nice contribution. I'm happy to merge it.
How does it impact performance when both gzip and brotli are enabled?
Should we enable brotli by default?

I didn't see much activity in this repo so I went ahead and published a fork to the marketplace, you can try it out here:
https://marketplace.visualstudio.com/items?itemName=dutzi.vscode-filesize-brotli
It seems ok, I didn't notice any difference.


Business Rule #001

Follow all regulations regarding monetary handling.

This is about 15 rules (at minimum) - should be targeted and several of these are included in the excel document we used to look up regulations


Netflix Home Page Clone

Describe the project
A Netflix homepage clone website made with only HTML, CSS, JAVASCRIPT and is fully responsive to all types of devices of different sizes, whether it is a laptop, tablet, or mobile phone.
Issue Type:

[ ] Bug Report
[ ] Feature Request
[ ] Documentation
[x] New Project

Additional context
Netflix Homepage Clone
Screenshots

Already present in the repo


modernflyouts: Add version <IP_ADDRESS>

close #3142
ModernFlyouts is a replacement for the built-in audio flyout UI, with a Modern Fluent Design.
Notes:

persist is not needed because config file is at $Env:LocalAppData\ModernFlyouts_Community.
~autoupdate cannot work properly without "replace": "${version}" in checkver.~ This is probably a bug in Scoop core.
UPDATE: The problem no longer happens in this manifest.
It happens when the 2nd matchgroup is named as version. (e.g. "regex": "(\\w+)\\.ModernFlyouts_(?<version>[\\d.]+)(\\w+)\\.Msixbundle")
checkver will be fine, but in autoupdate, $version becomes an empty string.

Screenshots:

/verify


Fix date format in csv files

Description
Date format of nested fields are modified according to advanced settingsDate format of nested fields according to advanced settings
Issues Resolved
#106
Check List

[ ] New functionality includes testing.

[ ] All tests pass, including unit test, integration test and doctest

[ ] New functionality has been documented.

[ ] New functionality has javadoc added
[ ] New functionality has user manual doc added

[ ] Commits are signed per the DCO using --signoff

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

The data used to test is the following, also have attached the csv report generated using it
data._source:  {   key1: {     key11: 'value11',     key12: '2023-04-26T04:34:32Z',     key13: '2023-04-26T04:34:32Z'   },   key2: '2023-04-21T04:34:32Z',   key3: 'value3',   a: { b: { c: '2023-07-21T18:40:01Z' } } }
fixed-csv.csv

The output CSV is still posting all days as Jan 01.
_index,_id,_version,_score,_source.key1.key11,_source.key1.key12,_source.key1.key13,_source.key2,_source.key3,_source.a.b.c
test_index3,test,1,1,value11,01/01/2023,01/01/2023,01/01/2023,value3,01/01/2023

I am going to strongly recommend you include the recommendations in issue #196.
Since the fix of this code is this far off the mark, the refactor recommended should take less than a day, and will improve testability and readability and help in debugging the issue at hand.

I added the wrong csv file, can you check this one?
correct-csv.csv


Add margins to labels

@afmckinney @jisqyv
I had thought I needed to wait for api4 to do this so it worked with different densities, but that's not necessary.

@halatmit Should the default really be true for hasMargins? This results in existing projects "growing" margins when they are loaded for the first time into the new version (the version with this change). To me this violates the principle of least surprise.
Perhaps the right thing to do is to have the form upgrader (which we do have) update loaded projects to set hasMargins to false when it loads an existing project. That way newly created labels will default to having margins while existing projects will load and look proper.
-Jeff

Having the upgrader set margins to false sounds like a good solution.
But it adds another issue to the list of issues waiting for the upgrader.
Lyn and Andrew:  Can we put on a full court press and get the upgrader done
in the next couple of days?
== Hal Abelson
<EMAIL_ADDRESS>Prof. of Comp. Sci. and Eng.
MIT Dept. of Elec. Eng. and Comp. Sci.
MIT Media Lab, Second Class Faculty
On Thu, Jan 1, 2015 at 8:38 PM, Jeffrey Schiller<EMAIL_ADDRESS>wrote:

@halatmit https://github.com/halatmit Should the default really be true
for hasMargins? This results in existing projects "growing" margins when
they are loaded for the first time into the new version (the version with
this change). To me this violates the principle of least surprise.
Perhaps the right thing to do is to have the form upgrader (which we do
have) update loaded projects to set hasMargins to false when it loads an
existing project. That way newly created labels will default to having
margins while existing projects will load and look proper.
-Jeff
—
Reply to this email directly or view it on GitHub
https://github.com/mit-cml/appinventor-sources/pull/198#issuecomment-68505029
.

@halatmit This change doesn't have to wait for the upgrader. It can be done in YoungAndroidFormUpgrader.

Super!  that would be great.
Please do it.  Or do you want me to figure out how? I'm not exactly sure
how to do this.
== Hal Abelson
<EMAIL_ADDRESS>Prof. of Comp. Sci. and Eng.
MIT Dept. of Elec. Eng. and Comp. Sci.
MIT Media Lab, Second Class Faculty
On Fri, Jan 2, 2015 at 11:11 AM, Jeffrey Schiller<EMAIL_ADDRESS>wrote:

@halatmit https://github.com/halatmit This change doesn't have to wait
for the upgrader. It can be done in YoungAndroidFormUpgrader.
—
Reply to this email directly or view it on GitHub
https://github.com/mit-cml/appinventor-sources/pull/198#issuecomment-68537893
.

I'll take care of it. You can then do the final review.
-Jeff

Thanks.
== Hal Abelson
<EMAIL_ADDRESS>Prof. of Comp. Sci. and Eng.
MIT Dept. of Elec. Eng. and Comp. Sci.
MIT Media Lab, Second Class Faculty
On Fri, Jan 2, 2015 at 3:29 PM, Jeffrey Schiller<EMAIL_ADDRESS>wrote:

I'll take care of it. You can then do the final review.
-Jeff
—
Reply to this email directly or view it on GitHub
https://github.com/mit-cml/appinventor-sources/pull/198#issuecomment-68559451
.

MERGED.  -Jeff


BuildDotenvConfig.rb failed on build

I'm used version: 1.3.3 and compiled sucefuly, but after update to: 1.4.0 I got this error on this file BuildDotenvConfig.rb line 4, xcode said we had syntax error on it.
I fix just did not update yet to 1.4.0 and using 1.3.3.

@jsimonassi Try to revert this changes
https://github.com/luggit/react-native-config/commit/0c42216725fd686b93900038e089fd71f9f75424
or hardcoded the prev hash in package.json
I hope it will be fixed soon.

@jsimonassi Have you checked if your .env file have spaces like  MY_ENV='foo'? Can you share the content of your .env file here to help us investigate this problem?

Doesn't matter content inside .env. there is an error I side ruby file with
new if condition someone forget to add 'end'
On Fri, Nov 6, 2020, 23:00 luancurti<EMAIL_ADDRESS>wrote:

@jsimonassi https://github.com/jsimonassi Have you checked if your .env
file have spaces like MY_ENV='foo'? Can you share the content of your .env
file here to help us investigate this problem?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/luggit/react-native-config/issues/519#issuecomment-723297332,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALFEOV6TZZIHOC3TO7TP7VLSORPWLANCNFSM4TMAXMTA
.

Thanks for the explanation @dubinam I think I fixed this problem in 1.4.1 version @jsimonassi Can you test with the 1.4.1 to confirm that problem is fixed?

Not sure if it's the same issue, but for me iOS build fails after updating from 1.3.3 to 1.4.1 because of empty lines and comments in env files: https://github.com/luggit/react-native-config/pull/516#issuecomment-724621992

My build is also failing, not because of empty lines but because of lines that are commented out.


GraphiteReporter does not report Gauge

I have been trying to use the HystrixCodahaleMetricsPublisher plugin to export Hystrix data to Graphite. (https://github.com/Netflix/Hystrix/tree/master/hystrix-contrib/hystrix-codahale-metrics-publisher) That plugin registers several Gauge<Boolean> objects to the MetricsRegistry.  I noticed, however, that the GraphiteReporter will ignore all of those since it does not include Boolean in its format method.
Can the GraphiteReporter be updated to handle Boolean values?

@efindley I had a similar issue and created a PR https://github.com/dropwizard/metrics/pull/921  If that ever gets merged, it should be simple to add Boolean to the mix.

Contributed in #905.


imlib2: 1.7.3 -> 1.7.5

Motivation for this change
Lib update ;
And use the proper license identifier (Imlib2 has its own license which is MIT-derivative)
Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.05 Release Notes (or backporting 21.11 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

@ofborg eval

On nixos x86_64:
builder for '/nix/store/405ivvvg23fzgd37ymxjkvvg16jv9v7i-giblib-1.2.4.drv' failed with exit code 1; last 10 log lines:
  checking whether build environment is sane... yes
  checking whether to enable maintainer-specific portions of Makefiles... no
  checking if malloc debugging is wanted... no
  checking for imlib2-config... no
  checking for imlib2 - version >= 1.0.0... no
  *** The imlib2-config script installed by imlib2 could not be found
  *** If imlib2 was installed in PREFIX, make sure PREFIX/bin is in
  *** your path, or set the IMLIB2_CONFIG environment variable to the
  *** full path to imlib2-config.
  configure: error: Cannot find imlib2: Is imlib2-config in the path?

I will look into that

Otherwise builds feh icewm openbox libcaca sxiv qiv fluxbox w3m e16 wmfs ... on nixos x86_64
Builds feh libcaca on macos 10.15

So giblib is a dead project (no more website, no sources) and the only thing depending on it (scrot) was updated upstream to use imlib2 directly and drop the dependency.
So scrot is updated and giblib is removed from nixpkgs.


not sure whats causing this crash and was unsure but i am guessing connector has something to do with it

Mod Name
Not sure
Mod Homepage
not found yet
Minecraft version
1.20.1
Describe the bug
Whenever i open a screen where i have to select items it crashes, for example: advanced xray block select screen and heracles quest book block icon select screen
Steps to reproduce

open a screen where you have to select blocks or items

...
Logs
https://gist.githubusercontent.com/Aabyiswack/c25f5f0cd155d0844940285aff51409f/raw/22c729bd1246c642a8be94d43cea28d68053577f/crash-2024-07-22_12.49.39-client.txt
Additional context
i will conduct a binary search when im sure sinytra is not exactly the one causing it, just need a confirmation so i can be sure b4 i start

Please read the issue template more carefully. For modpack related issues, use the support channel on our discord server.

Before reporting, please ensure that:

You've installed a minimal set of mods required to reproduce the issue.
Issues with modpacks and excessive amount of mods will not be accepted, as they take a long time to diagnose.
Knowing which mods are causing problems allows us to focus on fixing the issue as soon as possible.
If you're unsure which mods might be at fault, try using binary search - removing half of installed mods
repeatedly until the faulty mod is found.


Initialize form defaults from schema

Is this the right approach? How would I go about testing it?

Coverage increased (+0.1%) to 55.123% when pulling 9e749c24d51d35e987750f69f89e7dd66d04be66 on form-defaults into 32e40bcaf521d574172b7350a8801f0806ee24ee on master.


Move non-Grakn Dependency

What is the goal of this PR?
The current structure of dependencies/graknlabs/dependencies.bzl was breaking graql and sync-dependencies because it contained a non-graknlabs dependency.
What are the changes implemented in this PR?

Create a new package dependencies/python
move relevant rule from graknlabs/dependencies.bzl to python/dependencies.bzl
Update WORKSPACE correspondingly

@jmsfltchr just submitting a  quick patch so Graql becomes functional again! Only graknlabs dependencies can go into dependencies/graknlabs or graql gets confused!

@jmsfltchr just submitting a quick patch so Graql becomes functional again! Only graknlabs dependencies can go into dependencies/graknlabs or graql gets confused!

And even though @io_bazel_rules_python is hosted on a @graknlabs, it's not a Grakn Labs repo, because it's a fork of a different repo (in this case Bazel).

Ok all understood! I'll look out for this in future


Clarify Rustfmt 2.0 status

We've been using Rustfmt 2.0 from the rustfmt-2.0.0-rc.2 branch in a project for over a year. We need that because integration of Rustfmt with arc lint requires just formatting a set of filenames, and at the time only the 2.0 branch supported that (has that changed?). But it's a pain to install for developers because it requires nightly and that is broken a fair bit of the time.
It's a bit confusing what the state of Rustfmt 2.0 is. The rustfmt-2.0.0-rc0.2 branch name makes it sound like it is really close to release! However that seems not to be the case based on this comment:

2.0 development has been happening on the master branch for a long time, the rustfmt-2.0 branch hasn't had any activity because it hasn't been used/needed.
To be perfectly transparent though, rustfmt 2.0 may not happen ever, but even if it does it certainly won't happen any time soon.

But I don't see how Rustfmt 2.0 could be being developed on master given that it includes backwards incompatible changes, unless they're all behind flags somehow?
It would be really helpful if you could add a section to the Readme (or anywhere) about what's going on with Rustfmt 2. What changes does it include? How do you use them? Why it might / might not happen, etc.
Thanks!
PS: You might want to remove the bit about "when we reach 1.0" from the readme while you're at it.

If there are no plans to develop rustfmt 2 at the moment, then it would be nice to see some effort put into stabilizing all the unstable formatting options that exist. For reference, there are 25 stable options and 51 unstable options. The 1:2 stable:unstable ratio really makes this project feel unfinished as a user trying to configure rustfmt. If there were 60 stable options and 15 unstable, and active updates/movement on the stabilization tracking issues, I think things would feel a lot healthier.

I've been deliberately holding back on responding to this to ensure I'm in a good frame of mind before doing so. However, it's been well over a week and I still find it somewhat irksome and feel like I have to say that I really did not appreciate the characterization of the project as unhealthy and unfinished, particularly based on such a one-dimensional metric devoid of any context.
However, I've decided to choose to believe you said this with the best intent in mind responding to above comments. I'm not keen on having orthogonal discussions on closed issues, but I feel like this needs to be corrected and contextualize so I'll respond inline here while also trying to reframe and identify some actionable steps you could consider taking if you still have interest in seeing unstable options stabilized.
I realize the following is not a short read, but I think thoroughness is more important here given the mischaracterization.

Instead of making (incorrect) assumptions, I'd encourage folks to think about this in terms of the following questions:

Why are there so many options that are still unstable?
What can I do to help stabilize an option that I want to be able to use on stable?

As to the first, I think it's important to note there are several common misconceptions we see pretty frequently around config options.

the default posture should be to stabilize
an option has been around for X amount of time, ergo it should be stabilized
option works fine for me/I've had no issues with it, ergo it should be stabilized

These are all categorically false. We have a documented, explicit process for what's required to stabilize an option, and we won't stabilize any option unless and until we feel it clears all those thresholds. That's true regardless of whether the option is 5 days old or 5 years old. Put differently, the default posture is that unstable options will remain unstable unless and until they are provably demonstrated to be ready for stabilization; not the other way around.
Additionally, not all options are intended to be stabilized. Some have been flagged for removal (e.g. #5103, #5102, #5101), while others have already been deprecated but in a "soft" manner to try to give users more time to convert to the newer option (e.g. https://rust-lang.github.io/rustfmt/?version=v1.4.38&search=#merge_imports).
Furthermore, a large number of the unstable options have known bugs, commonly due to developers insisting on putting comments in strange places. An individual user/team can happily use such an option and never encounter one of those bugs, but that doesn't negate the fact that the bug exists and is experienced by others. These types of bugs have proven to be particularly thorny in the past and aren't necessarily quick/easy fixes.
The simplistic "there are X unstable options" line doesn't take any of that critical context into account.
The next point I'd stress is that many seem to be unaware of rustfmt's core scope, and thus the scope of the rustfmt team. First and foremost, rustfmt exists to pretty-print a parsed program's AST according to the rules defined in the Rust Style Guide. Full stop. That's our core mission and that, along with supporting/maintaining that function, is what takes priority. Other features we've been willing to take on, such as auxiliary formatting configuration options, are unequivocally secondary to that core mission.
This has two salient impacts on quantities of unstable config options. First, we're generally receptive to community desired configuration options (so long as the implementations won't require an unnaceptable maintenance burden), but only if someone from the community submits a PR with an implementation. Second, stabilization of config options is an inherently low priority, especially some of the community submitted options for more bespoke styling that diverges from, or even contradicts, the Style Guide. It's not uncommon for such options to be submitted by someone who only works on/cares about nightly who are happy to submit an implementation for nightly usage, but who aren't concerned about stabilization.
With the established priority level, the next relevant piece is the amount of bandwidth/capacity we have. Like the overwhelming majority of open source projects, rustfmt has far more work to do than it has people to do said work. For the last few years I've been the sole maintainer of rustfmt trying to accomplish what I can with whatever time I'm able to carve out of my personal life on nights and weekends. As many are hopefully aware, maintaining a project involves a significantly broader set of activities than writing code (or stabilizing config options), and I've had to handle the entirety of that breadth while also trying to avoid burning myself out and reducing the size of the team to 0.
Suffice to say, if we had more people we could get more done, including on lower priority items like config option stabilization. However, I fully anticipate that we'll continue to have a healthy number of unstable/experimental config options for years to come (even if that's due to currently unstable options being stabilized while new ones are added).
That is a good segue into the second topic relative to what one can do if they'd like to help, either just in general or for a particular option or two they'd personally like to be able to use on stable toolchains.
All unstable config options should have a stabilization tracking issue, the set of which can be found using the unstable option label (https://github.com/rust-lang/rustfmt/issues?page=2&q=is%3Aopen+is%3Aissue+label%3A"unstable+option"). Interested parties can start with one of those issue and compare it against the aforementioned stabilization criteria.
Note that one gap we have is bugs/issues for config options are not always explicitly enumerated in the stabilization tracking issues for every option, though they are in some (e.g .#4991). However, most of the time that blocking/bug/etc. information can be found within the issue tracker even if not explicitly linked/noted in the tracking issue, so even something as simple as adding comments to the tracking issue with links to bugs (or to confirm the absence of no bugs) is a helpful first step. Obviously submitted a fix for a blocking bug is massively useful as well. The utilization and well tested criteria are a bit harder to quantify, but again something as straightforward as github search results highlighting option utilization are helpful.

If you're willing/interested in helping, please let us know!

@calebcartwright thank you for your thoughtful reply. Respectfully, I think you're essentially confirming my critique. First, to be clear, my intention was not to take a stab at any individual or comment on their (your) ability as a maintainer. I didn't realize this comment would be difficult for you to process. From my side, I'm just calling things as I see/experience them as a user struggling to figure out how to use this tool and WTF is going on with it.
Regardless of your feelings surrounding the purpose of this project as a maintainer, this project is difficult to understand as a user. The problem of overwhelming unstable options, while I understand the concept of stabilization taking a longer time while also not being an explicit priority, does exists. It is cumbersome to parse through the long list of config https://rust-lang.github.io/rustfmt/?version=v1.4.38&search= and figure out what is going to work and what isn't. This isn't a damning problem in and of itself and some pretty simple solutions come to mind like housing unstable options below stable ones or on a different page. So it's not a problem per say that there is a 2:1 ratio of unstable to stable options, the issue is that it's silly to have to wade through 5.5k words of docs on a single page as a new (or any, really) user to the tool. It's also true that some of the most useful options for my needs are unstable but that's besides the point.
So this tool has a learning curve... so what? Now you've committed to wading through the mess of options. You come across an unstable option you'd like to use. Thankfully it does have a tracking issue. You visit the issue link. You read the thread. It was opened in 2017. There are comments every 3 months asking what needs to happen for the issue to be stabilized. Clearly there's community interest in supporting this configuration option. But, there's no movement from the project maintainers on stabilizing for 5 years. Somewhere in another thread you see the maintainers talking about how good things will be in rustfmt 2.0 and that's where the focus is. Then in another thread you see that rustfmt 2.0 is on ice. But... still no movement on stabilizing the existing options. This is what makes things feel unhealthy. Put yourself in the shoes of a user instead of a maintainer for a second: this state of the world is confusing and does not inspire confidence when asking the question "is this tool ready for prime time? should I adopt it on my team?".
In other words, you have a point that simply the number of unstable options is not a useful first order metric to gauge project health. However, from a user perspective it feels very much like a symptom of exactly what you go on to describe: this project lacks resources. Bingo! Take all the words/feelings and misconceptions and semantics out of it so we can laser in on the issue. You've admitted that you don't have the time you used to and are struggling to find opportunities to work on this project. You've felt the burn at times. There's a ton more administrative work than meets the eye and the team size is 0. The phrase "it's not your fault but it is your problem" comes straight to mind. Nobody is blaming you for doing a bad job. But the reality is that, by your own admission, this project doesn't have the resources needed to truly thrive. My comment was not intended to tell you something you already know. It was intended to make you aware that it's also pretty clear to users that something is missing with respect to this project.
The reason I'm being critical here is that while in the abstract single maintainer projects are fine and generally it's understood that people providing free time to the community don't owe anybody anything, rustfmt is part of the rust toolchain and should not be just some side hobby project. If you're feeling burnt out and without resources, the rust community should probably address that and do so very seriously. Honestly, I'd expect a bigger "call for help on rustfmt" type of announcement to the whole community rather than these small "read between the lines" glimpses of what's going on hidden in github issues here an there. The collective bar for this tool is higher and if the job of maintaining it has grown as rust has and you're needing help keeping up, that feels like it deserves more attention than a comment in a closed gh issue thread. Some times I'm bad at saying what I mean so to be direct: I'm trying to encourage you to reach out and find the help you need.
One of the asks I've seen from users while skimming the issues seems to be communication. So thank you, truly, for writing your thoughts down. I don't envy your position.

@dcow - I found your last response rather puzzling.
Simply put, I acknowledge we could do better on some issue triaging and documentation, but strongly reject your conflations and characterizations that I believe ultimately tie back to the project's goals and priorities not emphasizing things you'd like prioritized.

The phrase "first seek to understand, then to be understood" feels quite apropos here particularly given the number of more constructive ways you could've chosen to engage.
I feel we would've had a much more positive tone and productive dialog if you'd first reached out to us to ask some questions/get more information, shared feedback/ideas like "as a new user I found it difficult to differentiate stable vs. unstable options on the config page, and here's how I think it could it be better...", etc.
Let me restate this unequivocally: config options are bonus, low priority features. That's not my "perception as a maintainer", that's the truth. That priority holds regardless of resources, and even if I had 6 developers instead of 2, stabilization of config options still wouldn't get a ton of attention. Though I have no intention of doing so, we could in theory remove all the unstable config options tomorrow and the project would continue on executing on our goals and higher priority items.
Folks may not like the low priority status of config options, but they'll have to accept it regardless. We'll work on certain options when we can/when there's alignment with a higher priority goal, and I previously provided details on how others can help with an option they're particularly interested in (something others have taken us up on in the past).
You are of course entitled to your opinion and can certainly choose to believe whatever you want based on these bonus features not being a priority for us. However, we strongly dispute your overarching characterization for the reasons I've already thoroughly articulated and it seems pretty unreasonable to me to cast aspersions and make presumptions based on those low priority items not being worked on, or implying that a project can only be healthy or thriving if the maintainers work on the features you care about.
Could we do some things better? Absolutely! However, I think on the stabilization front that comes in flavors of issue categorization and adding relevant links to docs/bugs as we've alluded to in other threads. We're not going to do the highly ineffectual practice of periodically posting "no updates" nor acknowledging the repeated "bump" style comments either.
I'm not even going to attempt to respond to the rest of the points in your comment individually because they're all based on absolutely incorrect characterization that I will address to correct for any other readers.
rustfmt is categorically not my "hobby" project, nor am I "burned out" as you've apparently decided to state/imply. My prior point about resources was to note that we do not have a ton of extra bandwidth that could be allocated to low priority features and we've plenty of higher priority work to do. Furthermore, we aren't going to try to burn out the resources we do have by trying to work on both high and low priority items.

I don't think there's really anything else that can be said at this point that wouldn't be duplicative of prior comments, so I'm probably going to disengage from this thread.
To be frank, so far it feels like you've been more interested in stating your critiques than engaging in a mutual dialog, but I'm still open to discussing specifics in more focused forums (e.g. a new issue with suggested improvements for the config page) if you're interested. However, I'll also note that regardless of whether it was intended, your tone in the prior comment reads as somewhat patronizing and I'd ask that you be mindful of that if you do choose to engage in such discussions.

I have no idea how you interpreted my comment in the way you have. Maybe I've inadvertently struck a nerve with you. My apologies if I have. In the short while my initial
comment has been posted, it's received 3 thumbs ups. So I don't think I'm coming in here non-constructively.
I can assure you I'm not simply annoyed that you won't work on config options. It's not about not getting my way. That's not what any of this is about. And if you choose to interpret my comments that way then unfortunately there's not much further this conversation can go.
I've genuinely tried to offer you advice from an outside perspective based on essentially my anecdotal experience and additionally the contents of your response to my initial comment which honestly to me sounds like that of a tired maintainer. That's all. I'm sure I'm not 100% on the mark, but instead of trying to take my comment constructively with a grain of salt, you pick at my tone and accuse me of being patronizing. Again I'm not sure if I've offended you and sincerely apologize of I have. My intention is simply to vocalize my experience grokking rustfmt with the hopes that my feedback may, even if only slightly, contribute towards improving this tool in the future.

I think it might help if I gave my critique a different spin. Ignore everything I have to say about the soft stuff since I don't know what I'm talking about. Here's the hard tractable issue: I had some time I was willing to give to help this project get some unstable options stabilized based on my initial experience discovering so many unstable options. When I went and tried to figure out how I could help, lack of clear communication surrounding the state of the project along with a "no update no response" type of philosophy when people ask what the status is on getting an option stabilized deterred me from investing the time I had. If the status and work left to do on the outstanding unstable options was clear, I suspect I would have been able to contribute in a more meaningful way. That's all there really is to it and hopefully that's a framing that speaks more directly your language as a maintainer. Seriously, no hard feelings.
One final comment: if the goal of this project is "pretty print the ast according to the rust style guide and config is bonus" then I probably came in with a misunderstanding regarding the utility of rustfmt. I could be entirely to blame for that, but my interpretation, just so you know where I was coming from, was: "I see a tool rustfmt, I see a rather extensive list of options, skimming the options it looks like this tool will work for us since e.g. we use this brace style and etc.". I'm not sure where I was supposed to pick up on the idea that the config options are purely bonus. I think it's pretty fair to expect that if the tool is configureable and there is documentation published explaining how to configure it, that people will expect to be able to rely on that aspect of the tool being supported.

@dcow there's no hard feelings and nothing has been taken personally.
I feel like you're now trying to retcon things a bit, but you have finally gotten to a couple more concrete topics so I will reiterate my prior comment and suggestions around constructive routes you could take if you do indeed want to help or share some more actionable ideas.
You opened with a short abstract ask that we work on config options and shared your perception about the project.
I responded directly to that with background about the focus of the project, our team, and priorities to explain why we're not going to do that and why I disagree with your perspective. I also acknowledged some things we'll try to do better on, and enumerated some specific, concrete steps that you or anyone else can take if you'd like to help, either in general or on stabilizing a specific configuration option.
You then decided in response to expand to a broader critique and issuing more directions for me/our team. You're welcome to share your opinions, and yes, share experiences. However, doing a drive by critique of project you aren't familiar with to share unsolicited, largely abstract "advice" and lecturing isn't particularly helpful especially when you didn't seek to gain any understanding or context from us first. It shouldn't be too surprising to hear that isn't helpful and didn't land well.
I tried several times to pivot the conversation to some more actionable steps, but you still seemed more focused on making assertions and offering your critiques and advice based on your assumptions. I'm going to lock the issue because as I stated originally, this is an off topic thread on a closed issue. I think you've been given more than ample opportunity to express your complaints and critiques, and this has reached a logical conclusion.
Finally,

I had some time I was willing to give (and may have more in the future) to help this project get some unstable options stabilized based on my initial experience discovering so many unstable options. When I went and tried to figure out how I could help, lack of clear communication surrounding the state of the project along with a "no update no response" type of philosophy when people ask what the status is on getting an option stabilized deterred me from investing the time I had. If the status and work left to do on the outstanding unstable options was clear, I suspect I would have been able to contribute in a more meaningful way

I think this gets to the heart of part of this. First, I'm sorry to hear that and I also understand the perspective/critique you've been sharing. However, one of the points I've been trying to make is that I'd suggest you consider asking how you can help next time (regardless of whether it's this project or another) instead of jumping to conclusions. The comments you are referring to are people asking repeated questions like "when will this be stabilized?" not "is there anything I can do to help?". The former are repetitive, excessive, and have been  already been answered (though as I've acknowledged several times not in every instance) so are sometimes ignored. The latter are helpful, appreciated, but rare.
I don't understand why the presence or lack of response to the former would make you refrain from asking the latter, but thanks for sharing.

I feel like you're now trying to retcon things a bit,

I'm trying to find a way to communicate with you because I'm genuinely trying to share feedback that I think can help make this project better. I realized that because you've unfortunately interpreted my commentary as unsolicited, abstract, and "drive by" in nature it's made it hard for you to receive it so I'm trying to drop that avenue since it doesn't seem to be an effective way to communicate with you. If that's retcon then whatever I'm guilty. If it's what I have to do to find a way to be heard and not disregarded then fine.

You opened with a short abstract ask that we work on config options and shared your perception about the project.

One which is apparently shared by others. Look. My intention was to equip you with the knowledge that this perception is out there regardless of whether it's fair or not in your eyes or even apropos. Honestly I calibrate towards oversharing my thoughts because, if the roles were reversed, I'd much rather know what's on people's minds than not. Even if I totally disagree and find it unpalatable like you do.

I don't understand why the presence or lack of response to the former would make you refrain from asking the latter, but thanks for sharing.

Because, and forgive me if this is more unsolicited commentary my intention is only to share my contesxt, as a passerby briefly encountering this project, the distinction that exists clearly in your head is not a nuance that is on my mind. I see lack of response as lack of engagement.
So if we can agree on one thing, it's that config options aren't a priority for this project. I've shared that, given the large number of unstable ones, the experience as a user was that of "hmm this feels incomplete, it would feel more complete if some of these could be stabilized so that I didn't feel like I was searching for stable options amongst a bunch of unstable ones and because the things I need to effectively incorporate this tool are unstable". And then, rather than trancing along in apathetic bliss, I shared as much here.
Hopefully I avoided


Add Changes By Version

Task
A clear and concise description of Task
Task List:

[x] add changes by version

Please read the Contribution Guideline before submitting the PR

Done!


When create with --sass, npm build does work, main.js is missing.

94% asset optimization
100%
mv: no such file or directory: .../build/static/main.js
Done: 9662.041ms
Couldn't parse bundle asset "...\build\static\main.js".
Analyzer will use module sizes from stats file.
Webpack Bundle Analyzer saved report to ...\build\static\report.html
Something is wrong when sass project is created..
Dev server and portal work just fine. @supnate Suggestions?

Thanks @Cybermage83 for reporting this. It's not an error but a case not well handled. Don't need to worry about it. I will remove the error msg in the next release.

Just did true webpack build, got this error, which is probably why i am not generating the main.js
[./styles/index.scss] ./styles/index.scss 328 bytes {0} [built] [failed] [1 error]
+ 621 hidden modules
ERROR in ./styles/index.scss
Module parse failed: E:\Afigma_Corporation\ARK\src\styles\index.scss Unexpected character '@' (2:0)
You may need an appropriate loader to handle this file type.
| // index.less is the entry for all styles.
| @import './reset.css';
| @import './global.scss';
| @import '../features/home/style.scss';
@ multi babel-polyfill ./styles/index.scss ./index

There should be no less-loader in webpack-config.js. Could you check?

there was one on scss rule, as a final fall back.
also, i got it work, but i had to create a new non functional webpack.config.js and then run webpack to generate main.js after that i could to npm build so that timestamp can be assigned.
I am on windows machine, I don;t know if it matters, but something is weird going for a sass build

Okie, just did a server run, and got this:
ERROR in ./src/styles/index.scss
Module parse failed: ...\src\styles\index.scss Unexpected character '@' (1:0)
You may need an appropriate loader to handle this file type.
| @import './reset.css';
| @import './global.scss';
| @import '../features/home/style.scss';
@ multi react-hot-loader/patch webpack-hot-middleware/client?http://<IP_ADDRESS>:6075 ./styles/index.scss ./index
webpack: Failed to compile

OKie it looks like i found the real culprit >>
loader: isDev ? 'style-loader!css-loader?sourceMap!sass-loader?sourceMap'
: 'style-loader!css-loader!less-loader'
Right here... definitely need a fix here heh

I did find an error in the generated sass project. In webapck-config.js there's a less-loader for scss files, it should be sass-loader:
{
test: /.scss$/,
loader: isDev ? 'style-loader!css-loader?sourceMap!sass-loader?sourceMap'
: 'style-loader!css-loader!sass-loader'
}
I've not found why it just works on my machine, will investigate.

cool, glad we got that figured out. Thanks.

The bug was fixed in the latest 2.0.6 version.


join_with fails with concat

>>> join_with(concat, [{1: [1,2]}, {1: [2,3]}])
{1: [[1, 2], [2, 3]]}

I was expecting
{1: [1, 2, 2, 3]}

join_with() is designed to work with aggregating functions, i.e. taking single sequence argument. concat() expects many arguments. In your case one should use cat():
>>> join_with(cat, [{1: [1,2]}, {1: [2,3]}])
{1: [1, 2, 2, 3]}

Thanks!


BAML formatter implementation (Partial)

Adds a baml format subcommand for formatting files.
Formatter is a WIP, and writes out files from x.baml to x.formatted.baml to avoid clobbering the original file.
Example syntax it can format in its current state -
========= before ==========
class Foo {
}
------------ > ------------
class Foo {}
========== after ==========

========= before ==========
class Foo { field1 string }
------------ > ------------
class Foo {
    field1 string
}
========== after ==========

========= before ==========
class Foo {

    field1 string
}
------------ > ------------
class Foo {
    field1 string
}
========== after ==========

========= before ==========
class Foo {
    field1   string|int
}
------------ > ------------
class Foo {
    field1 string | int
}
========== after ==========

[!IMPORTANT]
Add baml format subcommand to CLI for formatting BAML files, outputting to a new ".formatted.baml" file.

Behavior:

Adds baml format subcommand to format BAML files, outputting to x.formatted.baml.
Formats class definitions and field types with specific syntax adjustments.

Implementation:

Implements format_schema() in formatter/mod.rs to handle BAML syntax.
Adds FormatArgs in format.rs to manage file paths and execution.

Dependencies:

Adds pretty and unindent dependencies in Cargo.toml for formatting support.

CLI Integration:

Updates commands.rs to include Format command.
Adds format.rs to handle the format command logic.

This description was created by  for 78c8476fce7fd75abd6ad3b131194ee1d467c21d. It will automatically update as commits are pushed.

amazing! glad to see that it was possible to get a proof-of-concept going so quickly, thanks so much!

Made a quick change to not fail on unhandled pest rules when ran via baml-cli fmt so it can be used on files without the formatter being fully complete.


🚀 Feature: unique cluster names

🔖 Feature description
Let's ensure that the name field of a cluster is a unique identifier. More specifically, if I make a request to the /api/kubernetes/clusters endpoint, the JSON array returned should contain objects such that each name value appears exactly once.
🎤 Context
From my perspective, a nice thing about this is that the bug #15901 would no longer occur. Moreover, having some kind of unique identifier is probably intuitive for integrators (I know I would have expected it when I first started with Backstage), and is a small step towards #13727.
Now there have been some valid criticisms of the difficulty of generating consistently unique names, and also the likelihood that such names will not be human-readable. The latter I hope should be addressed by #21398.
✌ Possible Implementation
The first thing I would try is modifying the CombinedClustersSupplier to check every single cluster it processes and make sure it hasn't seen its name before, throwing an error if it sees a duplicate:
https://github.com/backstage/backstage/blob/fc92656e4290aece5f332c2f4f54af50903afe5d/plugins/kubernetes-backend/src/cluster-locator/index.ts#L27-L41
At first, though, this might be too aggressive. Maybe we setup a migration plan for this; first just have the combined supplier log a warning to learn a bit more about possible sources of duplication.
As of now, I can think of two such sources:

I'm pretty sure that, based on issues like #13793 and #15668, the presence of AwsEKSClusterProcessors in the ingestion system can result in ambiguous cluster names.
the ConfigClusterLocator itself doesn't validate that the clusters it processes have unique names -- this would be pretty easy validation to add on startup.

👀 Have you spent some time to check if this feature request has been raised before?

[X] I checked and didn't find similar issue

🏢 Have you read the Code of Conduct?

[X] I have read the Code of Conduct

Are you willing to submit PR?
Yes I am willing to submit a PR!

@mclarke47 can this be closed? :pray:

I would like to find time to fix this but that doesn't seem like it's gonna happen soon


Pr/v1 api

Related questions/thinking:

what's the versioning/release plan, e.g. what are user-facing SDK API changes (if any), worth writing those up to include in the CHANGELOG.
with that, if there are some user-facing SDK changes, we can consider whether to maybe "deprecate" without hard-breaking things

I think I see (1) seed, (2) format, (3) word-duration changes. (1) and (2) are default changes we probably want to make, and folks can update their code to specify the old values if needed.
(3) probably isn't being used by anyone yet, so I think ok to change, but we should highlight it in notes. The rest seems like functionality-adds we should bullet.

Related questions/thinking:

what's the versioning/release plan, e.g. what are user-facing SDK API changes (if any), worth writing those up to include in the CHANGELOG.
with that, if there are some user-facing SDK changes, we can consider whether to maybe "deprecate" without hard-breaking things

I think I see (1) seed, (2) format, (3) word-duration changes. (1) and (2) are default changes we probably want to make, and folks can update their code to specify the old values if needed.
(3) probably isn't being used by anyone yet, so I think ok to change, but we should highlight it in notes. The rest seems like functionality-adds we should bullet.

BTW -- you can do the CHANGELOG and version bump, etc. as separate PRs from this one.


getUserId.js isLoggedIn has a Cognitive Complexity of 25 (exceeds 5 allowed) and has 43 Lines of Code (exceeds 25 allowed)

Code Climate Link
Code Climate estimated time to fix: 3hours
@Afrodo1 and I have brought discussed not really understanding what this code means with the use of the ctx parameter within this function.
This could be fixed with the resolution of Issue #43 as we are rehauling authentication

 Codeclimate Score of D with 23 Issues

 Refactor utils/

Lambda's Code Climate docs have been updated to include a switch in the codeclimate.yml file to turn off similar code checks. Reasoning is that they lead to too many false positive which seems to be the case for most if not all of these duplication issues.
They've also including an option to increase the threshold for # of lines to 50 which is more reasonable for Javascript.

Labs Code Climate Docs
Code Climate - Advanced Configuration

PR #54 is open for review

 Update Code Climate Configuration to ignore false positives for similar code checks, and update the line # threshold for methods/functions

Line threshold issue has been removed from maintainability report.


Vulkan: Particle ramp textures are set to repeat, causing visual artifacts when they restart

This is my first issue report ever so I hope everything is correct.
English is not my mother tongue so please understand..
Godot 4 Alpha 6
Issue description:
So there are a few Bugs with the GPUParticles2D.
I recommend to look in the project because it's very hard to descripe the bugs.

If you use a colored gradient with transparent at the end, then the particles at the end of their lifetime are suddenly displayed again in the color that is at the beginning of the gradient
At the start the particles have the last Color from the gradient. This happens when you have a high amount of particles.
If the FPS are set to 30 in the particles and you change the amount, there are a lot of visual glitches happening

Here is the 3. issue in my project: https://twitter.com/proj_Aetheria/status/1512212234952491014
I created an example object with all the things + A video.
Project.zip
I also have a small improvement suggestion for the gradient handling.
If you drag the slider in the gradient, for example, from the far left to the far right with the mouse and you want to undo it, then you have to press ctrl+z 1000 times because it tracks every color on the way. Maybe the retraction point should be where you started with the mouse?
Edit:
I thought of 2 new things that I had the last few days

When I first add the Color Gradient to the Particle - Nothing happend. Reload the Scene fixed it. This happens everytime when I create a new Particle with Gradient
I'm using an Animated Texture in the "texture" property. Sometimes in the Editor the animation doesn't work. When I run the game everything is ok. This only happens sometimes in the Editor. Fix -> Restart Godot

Thanks for your bug report. I have transferred it to the main Godot repository which is where we track bug requests. You posted it on the Godot-docs page which is where we track issues with the engine documentation.
It sounds like 1 and 2 are the same root cause, the gradient texture appears to be set to "repeat" instead of being set to "clamp".

Related to https://github.com/godotengine/godot/issues/56691 and https://github.com/godotengine/godot/issues/56886.

This seem to happen with CurveTextures as well. Tried it on particles Scale and scaling them down over age but just before they de-spawn they'll popp back to start size.

@fire-forge I opened a PR right before your comment (#60378) Please review when you have the chance!

@clayjohn I was referring to the Gradient editor undo/redo bug. But I will try to review your PR anyways.

@fire-forge Whoops! My bad.

But I will try to review your PR anyways.

Much appreciated :)


Preparing graphics and textures

hi what do you use to prepare the textures in the examples shown?

Currently there's no standard texture conversion tool. For the moment you can either use PNG (take a look at the gpusprites example), or smea's conversion script.


Duplicate functions in LinkedDataService

our linkeddata-service-won.js contains several sets of functions that seem to do (roughly) the same thing - an opportunity to refactor and simplify the whole thing so it doesn't take more than a day to become confident in making changes there.
this redundancy atm is a potential cause for hard-to-track-down bugs. e.g. several of the functions were missing a requesterWebId, which has been necessary to query events of a need for quite a while now.
e.g.
won.getConnection = function(connectionUri) {...}
won.getconnectionUrisOfNeed = function(uri) {...}
won.getConnectionWithOwnAndRemoteNeed= function(ownNeedUri,remoteNeedUri){...}
won.getConnectionsWithOwnNeed= function(ownNeedUri){...}
won.getConnectionInStateForNeedWithRemoteNeed = function(uri,connectionState) {...}
won.getConnections = function(uri) {...}
won.getConnectionContainerOfNeed = function(needUri) {...}

won.getRemoteConnectionUriOfConnection = function(connectionUri){...}
won.getRemoteneedUriOfConnection = function(connectionUri){...}

won.getLastEventOfConnection = function(connectionUri, requesterWebId) {...}
won.getLastConnectionEvent = function(connectionUri, requesterWebId) {...}
won.getConnectionEvent = function(eventUri, requesterWebId) {...}
won.getEventsOfConnection =
won.getAllConnectioneventUris = function(connectionUri, requesterWebId) {...}
won.getLastConnectioneventUri = function(connectionUri, requesterWebId) {...}
won.getLastEventOfEachConnectionOfNeed = function(needUri, requesterWebId) {...}

is this still an issue after linting and code refactoring?

Yep. Linting can't find non-trivial redundancies and code-duplication for us. Also it can't deal with the way the won.js and linkeddata-service.js are declared, i.e. it can't autocomplete and find usages etc  Generally, unused functions are only found within a file.
The solution here would be to switch those two files to es6-style export statements, remove unused functions (atm this means searching the codebase for each function-name), and lastly to make sure the functions reuse each other instead of solving the same problem over and over again.


Consistently use argparse, multiline output strings and dedent

Closes issue #57. Closes issue #58.

Merge. Tag in master branch as v0.6.2 and continue testing.


Infrastructure - helm experience link

When clicked should lead tovhttps://komodor.com/helm-dash/

@chad11111  I would love to take this.

Fixed in #303


Add short descriptions and maturity levels

add short descriptions in metadata.annotations.descriptions
add maturity levels from a list of [Basic Install < Seamless Upgrades < Full Lifecycle < Deep Insight < Auto-Pilot] according to https://github.com/operator-framework/operator-sdk/blob/master/doc/images/Operator-Maturity-Detailed.png in spec.maturity

/approve

@dmesser If maturity is based on the docs in operator-sdk, we should add a reference to it in our required fields doc.

rebased

/lgtm


Drop old versions from vendor/

Hey, I tried some of the new changes in 0.1.9 today and they're working great.
One request would be a mechanism to remove old versions as they aren't used. It's understandable that we wouldn't want this on-by-default in case there is one vendor directory being shared between different crates or workspaces.
However, in a one-workspace environment, there isn't a great way to do this short of rm -r vendor/ ; cargo vendor, which works but feels a bit strong of a hammer for the task.

Yeah so originally cargo-vendor was supposed to work a little differently, but nowadays I don't think the original conception makes sense. With the ability to pass multiple manifests via a bunch of -s flags I think it makes sense for cargo vendor to totally own the vendor directory and actually by default delete all of it.
Basically I'm thinking:

By default, cargo vendor is the equivalent of rm -rf vendor; cargo vendor
There's an option, --no-delete-vendor, or something like that to avoid the previous rm -rf

How's that sound?

That seems ok to me. Removes the optimization of skipping unchanged crates,
but that's probably fine.
We currently overlay some Bazel BUILD files in the dirs, but we can recover
them with a fancy git checkout command, so this will work for us.
Thanks
--Nipunn
On Wed, May 17, 2017 at 7:21 AM Alex Crichton<EMAIL_ADDRESS>wrote:

Yeah so originally cargo-vendor was supposed to work a little
differently, but nowadays I don't think the original conception makes
sense. With the ability to pass multiple manifests via a bunch of -s
flags I think it makes sense for cargo vendor to totally own the vendor
directory and actually by default delete all of it.
Basically I'm thinking:

By default, cargo vendor is the equivalent of rm -rf vendor; cargo
vendor
There's an option, --no-delete-vendor, or something like that to
avoid the previous rm -rf

How's that sound?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/alexcrichton/cargo-vendor/issues/36#issuecomment-302105591,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABPXo7haVxJ0FmpDB1iRzMXasP7lVwl_ks5r6wJvgaJpZM4NdNOc
.

Ok, I've opted to just delete folders that look like they've got a Cargo.toml in there and are as a result managed by cargo-vendor, it should leave other folders/files intact.


docs: add link of universe docs

Signed-off-by: Shumpei Wakabayashi<EMAIL_ADDRESS>Description

IMO, universe docs https://autowarefoundation.github.io/autoware.universe/main/ is not well known
because it is only linked at https://autowarefoundation.github.io/autoware-documentation/main/support/docs-guide/  and few people may find it.
In order to encourage people to find it,
I propose

Paste universe docs link here

Write link as this PR.

Write link in https://autowarefoundation.github.io/autoware-documentation/main/design/ by https://github.com/autowarefoundation/autoware-documentation/pull/86#discussion_r870009574

Pre-review checklist for the PR author
The PR author must check the checkboxes below when creating the PR.

[x] I've confirmed the contribution guidelines.
[x] The PR follows the pull request guidelines.

In-review checklist for the PR reviewers
The PR reviewers must check the checkboxes below before approval.
[ ] The PR follows the pull request guidelines.
Post-review checklist for the PR author
The PR author must check the checkboxes below before merging.

[ ] There are no open discussions or they are tracked via tickets.

After all checkboxes are checked, anyone who has write access can merge the PR.

I added the URL to the About section.

But it's also good to add the link in README. :+1:

FYI, a reference about link text. https://developers.google.com/style/link-text

@LalithVipulananthan Could you check this? :pray:

In the main Autoware documentation, perhaps we need to explain the difference between the main Autoware documentation and the Universe documentation?

@LalithVipulananthan
You mean this PR cannot explain the difference of the Autoware documentaion and Autoware universe documentation?

@LalithVipulananthan

We should also make sure that we update the README files for other repositories in the AWF org too.
I agree and I will make another PR.

@shmpwk I had a check and there's only a few repositories that need to be updated:

https://github.com/autowarefoundation/autoware_common (already submitted a PR to update this one)
https://github.com/autowarefoundation/autoware.core
https://github.com/autowarefoundation/autoware_launch
https://github.com/autowarefoundation/autoware_common

I had a check and there's only a few repositories that need to be updated:

Thank you. I made thier PR.
https://github.com/autowarefoundation/autoware_launch/pull/47
https://github.com/autowarefoundation/autoware.core/pull/36
https://github.com/autowarefoundation/autoware_common/pull/78


Update "github-integration" module

Update gradle version
Update spring version

TODO

[ ] Fix tests

Codecov Report

Merging #1297 (cf0bbcf) into master (942481e) will increase coverage by 12.06%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             master    #1297       +/-   ##
=============================================
+ Coverage     76.02%   88.09%   +12.06%
=============================================
  Files           187       32      -155
  Lines          2937      378     -2559
  Branches        508       55      -453
=============================================
- Hits           2233      333     -1900
+ Misses          435       32      -403
+ Partials        269       13      -256

Impacted Files
Coverage Δ

...lando/zally/integration/github/PullRequestEvent.kt

cli/zally/domain/violation.go

...in/org/zalando/zally/ruleset/zally/ZallyRuleSet.kt

...rg/zalando/zally/ruleset/zalando/ZalandoRuleSet.kt

...lly/ruleset/zalando/SnakeCaseForQueryParamsRule.kt

cli/zally/readers/yaml_reader.go

.../kotlin/org/zalando/zally/dto/ViolationsCounter.kt

...do/zally/ruleset/zalando/SecureAllEndpointsRule.kt

...zally/ruleset/zalando/PascalCaseHttpHeadersRule.kt

...ally/exception/InaccessibleResourceUrlException.kt

... and 143 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 942481e...cf0bbcf. Read the comment docs.

Decided to remove this module since there is no interest on it.


readMWRresults warning for incorrect characteristic names

Maybe we should have a warning instead of an error for incorrect characteristic names in the results file.  Since we want to provide the ability to pass data through R to the WQX file even if they are not using the QC functionality, we probably want to allow the possibility for them to send things through that don't match our parameter list.  For example, if they are sending a parameter through, like gage height, they might have their own mapping set up in WQX and not care if it is evaluated in R.  I think we just want to pass it through with a warning only.  It would be ignored in the QA/QC and Analysis functions.  Ignored in QA/QC if there is no DQO value for it, and ignored in Analysis if we don't have it in the parameter mapping table.
However, I do think that the every parameter in the DQO files should be in the parameter mapping table.

Agreed - these should pass through with only a warning.

For result unit, can we make it an error if the characteristic name is valid and only a warning if the characteristic name is invalid (per above)?

@ben-wetherill the checks in your last comment will only work if I have a parameter name in the mapping file to compare to in the results file.  So, I can produce an error only for valid characteristic names, but I have no way of know what's invalid (the list could be very long theoretically).  In other words, there would be no way to produce the warning.  But I agree, it will have to run the check only on the 'valid' parameter names in the mapping file.

Ah yes, you're right.


Problems with pipelineFunctions in AppSync

How did you install the Amplify CLI?
yarn
If applicable, what version of Node.js are you using?
v18.12.1
Amplify CLI Version
10.5.2
What operating system are you using?
Debian
Did you make any manual changes to the cloud resources managed by Amplify? Please describe the changes made.
none
Describe the bug
Hi, I am using the documentation specifically for Extend Amplify-generated resolvers https://docs.amplify.aws/cli/graphql/custom-business-logic/#supported-resolver-slots, but I have errors in the creation of the pipelines functions inside appSync as shown in the following image of the project code.

You may notice that the displayed resources do not have the same information.
The queries are mixed up with the mutations.

I have another project with a similar case, however the only way to prevent this error is to use the Amplify CLI Version 8.3.0 with this version the pipelineFunctions are generated correctly.
Expected behavior
That each function belongs to its corresponding category.
Reproduction steps
1.- amplify push
Project Identifier
Learn more at https://docs.amplify.aws/cli/reference/diagnose/
✅ Report saved: /tmp/testamplify/report-1671766871682.zip
✔ Done
Project Identifier: a6aa7472df30643338c4f9766531972e
Log output

# Put your logs below this line

Additional information
No response
Before submitting, please confirm:

[X] I have done my best to include a minimal, self-contained set of instructions for consistently reproducing the issue.
[X] I have removed any sensitive information from my code snippets and submission.

Hi @eliecer2000  - thank you for raising this issue. I think what you're seeing is a side effect of function consolidation which is performed for AppSync functions to reduce the overall function count in a stack, we alias identical functions together, but as you've pointed out that can cause a confusing experience.
Similarly, if your custom resolvers have identical logic, you may see that those are aliased to the same name to reduce the number of resolvers created.
This is a bit of a rough edge, and can lead to confusion as you're seeing. I'll tag this as a feature request to improve the naming here if possible.


add ESP32

ESP32 is power-packed with hardware features. The high-speed dual-core processors along with the numerous built-in peripherals it is set to replace micro-controllers in connected products.

Thanks ! 👍


Add everything to session storage

This issue has been fixed with commit 5ff83f2540832f19beacdb5f6ca85682b77962f3. If new pages are added then we will need to reopen this issue.


Typeerror: can only merge series or dataframe objects a class 'pandas.core.frame.dataframe' was passed

File "D: \Python程序\因子入库0421\factor_ top_ pure_ czl_ 0421_ gtja191.py", line 323,
in BarraDataPreparelong
BarraMatrix long = pd . merge barraclass, industry，on=['code'，'date'], how= ' inner' )#在barra因子矩阵右侧追加行业哑变量矩阵
File "C: \Users \Administrator\AppData \Roaming \Python\Python38 \site - packages\modin\pandas \general.py", line 84,in merge
raise TypeError(
TypeError: Can only merge Series or DataFrame objects, a <class
pandas. core. frame .DataFrame' > was passed
anyone kowns how to deal with it? 0.0

@quinnnnnnnnn Are you mixing pandas and Modin together? It seems like that might be the cause.

@devin-petersohn, do you think we should allow our merge implementation to take in a pandas DataFrame as we allow to concatenate pandas DataFrame(s)?

It is not recommended to mix Modin and pandas. Pandas will not accept Modin inputs, so I don't think we should allow this interaction.
Separately, we can create something that does make them compatible, but users should opt-in to this behavior IMO.

I agree with both your statements. This should be put into the list for 1.0.
Aside: although passing a pandas DataFrame in a function that uses broadcast join algorithm would speed up the flow 😄

I think we may introduce a special descendant from modin.DataFrame which would be a very thin wrapper around pandas.DataFrame so Modin user would be able to construct this special object from their pandas df (serving as opt-in), and this special descendant wouldn't be distributing this dataframe, somewhat like PandasOnPython does.

I wanted to use Modin as a drop-in replacement for pandas.
However, there is a function in my data-preparation script that calls external functions that returns pandas DataFrame (let's say an API that returns a pandas DataFrame)
As a result, Modin is not a simple drop-in replacement since I have to refactor my code (i.e., modin.pandas.DataFrame(pandas_dataframe), and it cannot easily be automatized ). However, a solution that allows Modin to perform operations with pandas Series and DataFrame would likely allow those kinds of operations without having to think about it.

It is not recommended to mix Modin and pandas. Pandas will not accept Modin inputs, so I don't think we should allow this interaction.

@devin-petersohn  Could you develop that? Modin dataframe will not be compatible with pandas dataframes, but I do not see the potential harm in having Modin convert pandas dataframes to modin dataframes.
A code example that I would like to be able to use without refactoring:
import modin.pandas as pd  # replace previous pandas import
from my_company_data_utils import get_dataframe_of_something

df_pandas = get_dataframe_of_something() # returns a pandas dataframe
df_modin = pd.DataFrame({"A":[1,2,3,4]}) #

df_modin.merge(df_pandas, on=["A"])
# or
pd.merge(df_pandas, df_modin, on = ["A"])

However, probably that having df_pandas.merge(df_modin, on=["A"]) would likely imply modifying the pandas library, or to do hacky stuff such that all pandas  dataframes be converted into Modin dataframes automatically.

Separately, we can create something that does make them compatible, but users should opt-in to this behavior IMO.

That would be super nice!

@adrienpacifico thank you for commenting here. There is some demand to have interoperability beyond calling modin_df._to_pandas() and/or modin.pandas.DataFrame(pandas_df). We still haven't decided how that will work, though. I'll move the priority of this issue up to P1 for now.


found a double-callback

This was causing some silly errors. It was calling back twice.

You're absolutely right. Thanks! I'll push version 0.2.1 to npm right away.


scsi rebase

Summary of the PR
This is a rebase of https://github.com/rust-vmm/vhost-device/pull/4.
Requirements
Before submitting your PR, please make sure you addressed the following
requirements:

[x] All commits in this PR are signed (with git commit -s), and the commit
message has max 60 characters for the summary and max 75 characters for each
description line.
[ ] All added/changed functionality has a corresponding unit/integration
test.
[ ] All added/changed public-facing functionality has entries in the "Upcoming
Release" section of CHANGELOG.md (if no such section exists, please create one).
[x] Any newly added unsafe code is properly documented.

All commits in this PR are signed (with git commit -s), and the commit
message has max 60 characters for the summary and max 75 characters for each
description line.

Is there documentation of what signing means? I assume DCO, but I find it a bit weird to sign things without that having specified somewhere :)

All the code here was written by me (as best I recall; I'm generally pretty good about noting if it isn't). The work was done as part of GSoC, but I don't believe any copyright assignment takes place there.

Yeah, you had sign-offs on the relevant commits, mostly tried to make sure that the way I split up stuff is ok with you (since I put your name as main author). That said, we might be missing SPDX-License-Identifiers (at least current code has it, do not find anything in https://github.com/rust-vmm/community/blob/main/CONTRIBUTING.md). I would add: Apache-2.0 or BSD-3-Clause to all files, ok?

Incidentally, I had a scsi-write branch that may be of interest; there was sufficient write support to boot and run Debian, though I can't vouch for its correctness in the face of writeback failures - IIRC there's a tricky mismatch here between the level of detail SCSI expects and what the POSIX file APIs give us. I think I might just fsync everything, which is probably slow-but-good-enough?

I guess for now, I would aim at getting the readonly state merged. So I have not spent any thoughts on writes. Will check it out when I do so!

Please let me know if you have any questions, by the way! This was a couple years ago now, so no promises, but happy to try and remember what I was thinking.

Sure. Right now I focused on getting stuff work properly. Will let you know when I stumble over something. Feel free to provide review on the stuff that I changed!

Changelog (in order of significance):

Split the emulation interface into handling LUN-independent and LUN-specific messages

This allows the LUN-specific part to be oblivious to the target
Allowed for some de-duplication too

Create own trait to decouple from io::File
De-boilerplated the daemon by moving parsing to virtio.rs

Still requires some boilerplate to copy between virtio and scsi datastructures
Could be further simplified if we are fine with scsi-virtio-specific stuff returning datastructures of src/scsi/ (currently they were kept separated on purpose)

Removed no longer needed suppressing of linting (either due to simplified code or newer linter version)
Random cleanups here  and there

CI seems to be broken by dirty permissions from left-over jobs?

Open clarification items:

[ ] SPDX identifiers?
[ ] abstraction-levels: What should be public? Which parts do we want to allow other people to use?

"Just the daemon?" vs "daemon, virtio-scsi abstraction, target interface, inner-emulation interfaces (LogicalUnit)"?

[ ] How to test the daemon?
[ ] Meaning of signoff is not documented.
[ ] No CHANGELOG available.

abstraction-levels: What should be public? Which parts do we want to allow other people to use?

"Just the daemon?" vs "daemon, virtio-scsi abstraction, target interface, inner-emulation interfaces (LogicalUnit)"?

Currently, we have multiple layers of abstraction in here:

the daemon that allows connection to the socket, parses things using the virtio module and forwards things to the EmulatedTarget after registering a BlockDevice for each image.
virtio that abstracts some of the virtio-scsi related parsing and provides some convenience features
scsi::Target that abstracts over the actual backend (only consists of execute_command)
scsi::emulation::target::EmulationTarget that implements scsi::Target by maintaining a list of LogicalUnits, handling REPORT_LUNS and forwarding other commands to the LogicalUnits.
scsi::emulation::block_device::BlockDevice that emulates an actual drive against a BlockDeviceBackend
scsi::emulation::block_device::FileBackend that implements BlockDeviceBackend

Comparing that against https://github.com/rust-vmm/vm-virtio/tree/main/crates/devices/virtio-blk/src, my feeling is that there the virtio and high-level device-specific abstractions are sharing the same data structures.
With that, there are a series of choices that could be made:

About virtio parsing + scsi::Target:

Move it to https://github.com/rust-vmm/vm-virtio/tree/main/crates/devices.

Will probably require some extensive review and additions for features that we do not cover.
Unifying the two interface, would make the main.rs more simple, since no conversion is necessary.

Keep it here and public.

People could depend on this without consuming the rest, but it would not be as clean as pulling it from a separate crate...
We would probably at least still need to document this a bit better...

Keep it here, but mark it private.

Only our daemon would profit from it then.
we could mature it over time and eventually move it to https://github.com/rust-vmm/vm-virtio/tree/main/crates/devices.

No real benefit from defining separate scsi (virtio-less) and scsi-virtio interfaces though...

About the emulation-specific abstraction

Exposing these traits probably only makes sense if we also provide enough other support for the virtio layers in order to allow people to write their own daemon.
If we do not do that, we should probably just mark that API as crate-private.

I got no strong feelings about any of these options and are open to opinions.

I would add: Apache-2.0 or BSD-3-Clause to all files, ok?

@Gaelan: Can you confirm that your code is of that license (not finding where the implications of the sign-off are stated... Probably this is already agreed to by the sign-off, but better to double check...)?
I would then add a:
// SPDX-License-Identifier: Apache-2.0 or BSD-3-Clause

tag to all files.

Yes.

OK first a couple of minor things:

do we want to rename this to vhost-device-scsi to be more consistent with the others (maybe not as vhost-user-vsock also exists)
can we agree on standard parameter conventions, e.g. --socket-path even if we don't need to handle multiple

Finally when running with:
./qemu-system-aarch64 -cpu max,pauth-impdef=on -machine type=virt,virtualization=on,gic-version=3 -display none -serial mon:stdio -netdev user,id=unet,hostfwd=tcp::2222-:
22,hostfwd=tcp::1234-:1234 -device virtio-net-pci,netdev=unet -kernel ~/lsrc/linux.git/builds/arm64.initramfs/arch/arm64/boot/Image -append "console=ttyAMA0 init=/sbin/init"
 -m 4096 -object memory-backend-file,id=mem,size=4G,mem-path=/dev/shm,share=on -numa node,memdev=mem -smp 1 -chardev socket,id=scsi,path=/tmp/scsi.sock -device vhost-user-sc
si-pci,chardev=scsi,num_queues=1,param_change=off -d trace:vhost_\*,trace:vhost_user\*

I see the following crash:
✗  env RUST_LOG=trace RUST_BACKTRACE=1 ./target/debug/vhost-user-scsi -r /tmp/scsi.sock test.img
[2023-03-31T12:46:53Z INFO  vhost_user_scsi] Memory updated - guest probably booting
[2023-03-31T12:46:53Z ERROR vhost_user_scsi] Ignoring descriptor on queue 1
thread 'vring_worker' panicked at 'should fit into cdb: TryFromSliceError(())', /home/alex/lsrc/virtio.rust/vhost-device.git/crates/scsi/src/virtio.rs:103:18
stack backtrace:
   0: rust_begin_unwind
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/std/src/panicking.rs:575:5
   1: core::panicking::panic_fmt
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/panicking.rs:64:14
   2: core::result::unwrap_failed
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/result.rs:1791:5
   3: core::result::Result<T,E>::expect
             at /rustc/d5a82bbd26e1ad8b7401f6a718a9c57c96905483/library/core/src/result.rs:1070:23
   4: vhost_user_scsi::virtio::Request::parse
             at ./crates/scsi/src/virtio.rs:101:18
   5: vhost_user_scsi::VhostUserScsiBackend::handle_request_queue
             at ./crates/scsi/src/main.rs:117:30
   6: vhost_user_scsi::VhostUserScsiBackend::process_request_queue
             at ./crates/scsi/src/main.rs:92:13
   7: <vhost_user_scsi::VhostUserScsiBackend as vhost_user_backend::backend::VhostUserBackendMut<vhost_user_backend::vring::VringRwLock>>::handle_event
             at ./crates/scsi/src/main.rs:270:25
   8: <std::sync::rwlock::RwLock<T> as vhost_user_backend::backend::VhostUserBackend<V,B>>::handle_event
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/vhost-user-backend-0.8.0/src/backend.rs:393:9
   9: <alloc::sync::Arc<T> as vhost_user_backend::backend::VhostUserBackend<V,B>>::handle_event
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/vhost-user-backend-0.8.0/src/backend.rs:262:9
  10: vhost_user_backend::event_loop::VringEpollHandler<S,V,B>::handle_event
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/vhost-user-backend-0.8.0/src/event_loop.rs:223:9
  11: vhost_user_backend::event_loop::VringEpollHandler<S,V,B>::run
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/vhost-user-backend-0.8.0/src/event_loop.rs:197:20
  12: vhost_user_backend::handler::VhostUserHandler<S,V,B>::new::{{closure}}
             at /home/alex/.cargo/registry/src/github.com-1ecc6299db9ec823/vhost-user-backend-0.8.0/src/handler.rs:132:32
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

I see the following crash:

TODO:
[ ] support CONFIG in order to prevent hardcoding CDB_SIZE

[ ] support CONFIG in order to prevent hardcoding CDB_SIZE

turned out to be a different issues, dropping this as TODO for first milestone. Linux and QEMU currently seem to both use a fixed size
Changelog:

Added license tags
Fixed size of CDB (@stsquad this should fix your crash)
Started writing tests (more are needed)
Refactored daemon to match code structure of other daemons
Renamed to vhost-device-scsi
Renamed sock -> socket-path and turned into a named argument

TODOs:

[ ] make API private
[ ] add changelog file
[ ] expand tests

Changelog

test skeleton for testing vhu_scsi.rs
fixed clippy warnings
stricter LUN format check

TODO

[ ] some error-case tests

Changelog:

Extended tests with some error conditions

I think this could now be in a mergable state (pending any review comments of course)

Changelog:

Added support for CONFIG for testing with @stsquad's vhost-user-generic series (and for later Xen support)

Changelog:

rebased on origin/main
removed some fields that are not actually used by the current implementation
added WRITE(10), WRITE SAME(16) and SYNCHRONIZE CACHE(10) support
fixed an issue found by fuzzing (see https://github.com/Ablu/vhost-device/tree/scsi-fuzzing for the quick&dirty fuzzing code)

Changelog

fixed build
added some testing infrastructure

CI reports dropped coveraged. But that seems to happen because the CI reports slightly different percentages compared to what my local toolchain reports. I will adjust the number to make CI happy once this is reviewed. Overall the coverage improved, the failure is only happening because I bumped the percentage to what the script tells me locally.

Changelog

Rebased on top of main
Bumped dependencies to match other crates
Dropped unneeded dependency on queue test-utils

Changelog

Hopefully fixed coverage

This is just too much (and complex) code to review. I have looked at it from the perspective of vhost-device stuff and that it is implemented in a way similar to other crates in the workspace.
Approving it now.
@stsquad @mathieupoirier @stefano-garzarella

This is just too much (and complex) code to review. I have looked at it from the perspective of vhost-device stuff and that it is implemented in a way similar to other crates in the workspace.
Approving it now.
@stsquad @mathieupoirier @stefano-garzarella

I think its had some good cycles of review but there is a trade off to a growing stack of commits vs incremental updates. I'm happy with merging this so follow on enhancements aren't forever blocked.


Use justfile instead of makefile

Use casey/just for more features and modernization.

Nice to know this tool, I will consider using it in the AI service as well. 🤙🤙🤙


Supply a trait to allow user annotations to provide JsonProtocol type hints

This is one sketch of a solution to permit more flexible serialization and deserialization of user annotations defined outside of FIRRTL. Currently in FireSim, we use a hacked up version of the JsonProtocol to do precisely what's included in this PR.
I think it would be very easy to add an extra member to supply a custom serializer/deserializer but Json4s does a pretty good job by itself assuming you give it sufficient type hints. It can for instance handle type-parameterized case classes (see #1207), without needing to write a serializer.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

Naturally this breaks all tests that expected some fixed number of annotations...

I think it would be very easy to add an extra member to supply a custom serializer/deserializer but Json4s does a pretty good job by itself assuming you give it sufficient type hints. It can for instance handle type-parameterized case classes (see #1207), without needing to write a serializer.

I didn't realize that Json4s does such a good job, that's cool.
This looks mostly good. I'm not a huge fan of DeserializationTypeHintsAnnotation since this provides additional annotations that must be handled.
An alternative (that might not work) could be to put HasSerializationHints on the companion object of Annotations, then the JSONProtocol could (reflectively, ew) load the companion object of each annotation class, see if it mixes in that trait, and include the type hints if it does. Thoughts?

@Mergifyio backport 1.2.x


v1.7 patch (currently v1.7.3)

Fix #2158.
@PrettyWood are you happy with this? If so I'll release v1.7.3 asap.

@samuelcolvin When running test-fastapi, the repo is cloned and dependencies are automatically added.
The issue with the CI is due to new resolver in pip 20.3. There are already plenty of issues on the repo.
I guess we can:

skip fastapi tests (not really smart imo)
wait for pip to fix it (but how long will it take?) or fastapi to make changes in its deps
pin pip==20.2 (seems reasonable)
WDYT?

I've pinned pip

release is deploying now.


Allow higher keep-alive frequency for worker data server

RPC channels that are opened to worker are configured to send keep-alive pings every 30sec. This change increases worker server's tolerance to that default.

alluxio-bot, merge this please


Typescript validation for JS files should not run in Flow checked files by default

This is a duplicate of https://github.com/Microsoft/vscode/issues/15171 - which is closed, and so I'm opening this one as I don't think the issue is resolved.

VSCode Version: 1.41.0
OS Version: 10.14.6
Does this issue occur when all extensions are disabled?: Yes

Steps to Reproduce:

Create a folder with .flowconfig file
Create a file with the following:

// @flow
import { type Node } from 'react'

Open VS Code in this folder

You see the following error on hover:
Node
~~~~
',' expected. ts(1005)

Issue
This is a bad default experience. Can we disable typescript validation automatically, instead of forcing the user to disable JS validation in settings, which can negatively their experience when opening other projects?

From VS Code's point of view, flow files are just JS files. We don't want to get into the business of special casing *.js files that start with // @flow; that should be something that either users or extensions opt into
The correct workaround for flow project is disabling JavaScript validation


TabCompletion: Miscellaneous completion tests - Test completion with splatted variable

The following test is failing on Ubuntu 20.04 in PS 7.2.0-preview.7:
https://github.com/PowerShell/PowerShell/blob/945a23234170bd5ebdace8b6d10b82754354f68f/test/powershell/Host/TabCompletion/TabCompletion.Tests.ps1#L1026-L1031
The error message is:
Expected a collection with size 4, but got collection with size 2 @(System.Management.Automation.CompletionResult, System.Management.Automation.CompletionResult).

Probably related to https://github.com/PowerShell/PowerShell/pull/14623, I guess?

I think CI passed on that PR, which is strange

Possibly a mismatch between tests and pwsh (new tests running on old pwsh).

If there is old pwsh then only in release process because CIs are passed in PRs.


feature(pkg/driverbuilder): add minikube target

Signed-off-by: Aldo Lacuku<EMAIL_ADDRESS>

What type of PR is this?

Uncomment one (or more) /kind <> lines:

/kind bug

/kind cleanup

/kind design

/kind documentation

/kind failing-test
/kind feature

Any specific area of the project related to this PR?

Uncomment one (or more) /area <> lines:

/area build

/area cmd

/area pkg

/area docs

/area tests

What this PR does / why we need it:
This PR introduces a new builder for minikube, which uses the vanilla builder under the hood when building the drivers for the minikube distro.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

feature(pkg/driverbuilder): add minikube target

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by: alacuku
Once this PR has been reviewed and has the lgtm label, please assign dwindsor for approval by writing /assign @dwindsor in a comment. For more information see:The Kubernetes Code Review Process.
The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these files:

OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: alacuku, FedeDP
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS [FedeDP]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

LGTM label has been added.  Git tree hash: 74aa5dc15b0b8cb316edafde66709a164aee19e1


cargo -C dir does not use the rust-toolchain.toml file within the given directory.

Problem
Issue #10098 requested the addition of the -C <DIR> flag. This flag was added in #10952, which closed #10098. However, using the -C flag does not use the rust-toolchain.toml file from the given directory.
For context, see this note from issue #10098:

Regarding rustup and rust-toolchain.toml overrides, I'm inclined to say rustup should honor this flag as well and interpret it prior to locating an override file. The idea here is that saying cargo -C $path … should behave indistinguishably from running cargo within that path.

Steps

Run the following commands:

rustup default beta # since `-C` isn't released on stable yet
cargo new use-nightly

Create use-nightly/rust-toolchain.toml with the following contents:

[toolchain]
channel = "nightly"

Check the version of cargo being used with the -C option vs cd command and note the difference:

$ (cd use-nightly && cargo --version)
cargo 1.70.0-nightly (0e474cfd7 2023-03-31)
$ cargo -C use-nightly --version
cargo 1.69.0-beta.6 (713164a40 2023-03-26)

If you want to take this one step further, try using a nightly-only feature within the use-nightly directory. With -C it will fail, but with cd use-nightly && cargo build it should succeed.

Possible Solution(s)
No response
Notes
I'm not sure how practical it is to actually fix this issue, but wanted to call attention to it, especially since fixing this after it reaches the stable channel could break things for anyone who might depend on the current behavior.
If it is practical, and someone could point me toward the relevant code, I would be happy to work on fixing this myself.
Version
cargo 1.69.0-beta.6 (713164a40 2023-03-26)
release: 1.69.0-beta.6
commit-hash: 713164a40962a0a76c7f3ad8aafb6f03410e21d2
commit-date: 2023-03-26
host: x86_64-unknown-linux-gnu
libgit2: 1.5.0 (sys:0.16.0 vendored)
libcurl: 7.86.0-DEV (sys:0.4.59+curl-7.86.0 vendored ssl:OpenSSL/1.1.1q)
os: Pop!_OS 22.04 (jammy) [64-bit]

As you've pointed out, this is something related to cargo proxy in rustup. Cargo itself doesn't read stuff from rust-toolchain.toml. But yes, it is a bit confusing for users not familiar with the relationship between rustup and cargo, and I believe the majority of Rust developers don't know that. (It should be a implementation detail in general to me)
Simliar issue https://github.com/rust-lang/cargo/issues/11036.


add Spike to supported SSG for contentful

There's a well maintained plugin especially for this

I added another Headless-cms too (rooftop-cms)

LGTM


Add Getting Company Profile by ISIN or CUSIP

The Finnhub API provides the possibility to not only get the company profile by symbol, but by ISIN and CUSIP too. This enables

better interopability with other services
converting from ISIN -> symbol, etc.

This is important in some use cases, as these symbols aren't universal if compared by machines. I.e. one service uses "BRK.B" and another one (like Finnhub) uses "BRK-B".
I hope I found all places that need adjustment to deliver this change. Feel free to comment if I should change/improve/... anything.

Actually I just forked to create this PR ;-)


Shareware/1.21

patch leaves by 1.21

i cannot merge it after that because it will ruin shareware branch. i will stand by this. i should refrain from merging this


Sphinx error building the portal site locally

What happened:
I tried to build the portal site locally on my Mac laptop while developing #67. I followed the procedure for this described on our Contributor's Guide to set up and activate a dedicated conda environment and then build the site using sphinx.
I got the following error:
Theme error:
An error happened in rendering the page index.
Reason: TypeError("generate_nav_html() missing 1 required positional argument: 'kind'")
make: *** [html] Error 2

What you expected to happen:
The site should build normally without error.
Minimal Complete Verifiable Example:
From repository root directory:
cd content
conda env create -f ../ci/environment.yml
conda activate pythia
make html

Anything else we need to know?:
Environment:

Python version: 3.9.2
Sphinx version: 3.5.4
conda version: 4.9.2
Operating System: macOS Catalina 10.15.7
Install method (conda, pip, source): conda, as described above

@brian-rose I get the same error on our Linux server "lore" ... same environment save the OS, which is a RHEL7-like Linux OS.

I was curious why we're getting this build error but the builds on readthedocs are working.
I see now that readthedocs is using requirements.txt to define its python / sphinx environment and doesn't touch ci/environment.yml at all. So the two build environments are inconsistent with each other, which is not ideal.
Looking more closely, I see that ci/environment.yml seems to have extraneous stuff, including pydata-sphinx-theme which I don't think we're using at all.

The error goes away when I remove extraneous stuff from ci/environment.yml and make it consistent with requirements.txt
I will shortly submit a PR to fix this.
Longer term, I think we should base the readthedocs build on conda so it's consistent with our own local build instructions. That way we'll avoid this kind of bug in the future.

Yep, I can confirm as well ... in my case, I removed the pydata-sphinx-theme and then "make html" ran to completion.


VDC: investigate recovering if the master is lost

if the master node dies

we lose the embedded etcd of rancher

the workers are already configured against the old master (using its private network IP)

my suggestion would be deploy a new master on the same old private network IP and manually reset the workers state and redeploy the IP again on the master, and initiate the velero restore job again

IP Issue
the public IP is attached to the master VM, and if this master went done, we can't guarantee that the same IP will be attached to the new master. https://github.com/threefoldtech/tfexplorer/issues/318
Storage Issue
Currently there is NO guarantee for restoring the solutions data.
solutions
1- Use NFS volumes, but it's not supported on current k3s vms.
2- Use Glusterfs volumes, but it needs at least a cluster with 3 nodes.
3- Create a storage solutions on the grid, so it can be used with kubernetes volumes (IMHO it's the best solution as if the whole cluster is gone, the data will be stored)
4- Use quantum storage as hostpath for volumes, but I think it's not recommended for heavy write/delete solutions.
Solutions Issue
1- Restore solution with velero, this will reschedule all solutions, but the old one will be removed.
2- Deploy external etcd cluster, so it can be used as kubernetes back-end, but the problem is the minimum requirement for etcd cluster. https://github.com/threefoldtech/js-sdk/issues/2729


zgpu doesn't catch vulkan load error

When running a program using zgpu in a linux environment where vulkan is not available, a "null" adapter is acquired and the code path for handling the error is not reached.
I see 2 problems here:

Dawn should fallback to an OpenGL backend (out of scope for zgpu)
mach/gpu produces a Null adapter rather than an error and zgpu tries to treat this as valid

The end result is an empty window and the following stdout would not be visible to an end-user:
Error: Couldn't load Vulkan. Searched /home/chris/zig-gamedev/zig-out/bin/libvulkan.so.1, libvulkan.so.1.
    at operator() (/home/runner/work/mach-gpu-dawn/mach-gpu-dawn/libs/dawn/src/dawn/native/vulkan/BackendVk.cpp:201)
    at Initialize (/home/runner/work/mach-gpu-dawn/mach-gpu-dawn/libs/dawn/src/dawn/native/vulkan/BackendVk.cpp:206)
    at Create (/home/runner/work/mach-gpu-dawn/mach-gpu-dawn/libs/dawn/src/dawn/native/vulkan/BackendVk.cpp:168)
    at operator() (/home/runner/work/mach-gpu-dawn/mach-gpu-dawn/libs/dawn/src/dawn/native/vulkan/BackendVk.cpp:423)

[zgpu] High-performance device has been selected:
[zgpu]   Name: Null backend
[zgpu]   Driver:
[zgpu]   Adapter type: CPU
[zgpu]   Backend type: Null

Thanks for the report.
I think that we shouldn't support OpenGL. It can have different performance characteristic and also, as I understand, it is "best effort" implementation in Dawn.
I have added early check on Linux to make sure that Vulkan driver is installed, if it isn't we print error message and exit.
Please let me know what do you think about this solution.

I agree that relying on Dawn's OpenGL backend to function to any acceptable standard will be more pain than it's worth and that requiring Vulkan is best for zgpu.
Looking at the commit, I think it's a good solution, since the user of zgpu can now handle the error however they deem appropriate for the end-user, i.e. present a system dialog.