Add Platform

Should be rebased ...

It would have been rebased by github. But here you go

Here is the PR on the roc compiler, that is necessary for the platform to work: https://github.com/roc-lang/roc/pull/6542


cloneIncomingMessage does not handle headers field in Node.js v16

I met the problem described in the title. I've investigated it and found the cause.
The src/interceptors/ClientRequest/utils/cloneIncomingMessage is not properly.
But I don't know how to fix it properly. I'm planning to consider it but first I share it via this issue.
--- Edit
I removed the meaningless tests.

Sorry. The proposed test improvements don't seem to make sense.
It seems to pass on Node.js v12 but not on the Node.js v16 or higher.

The issue here seems to be related to the fact that cloneIncomingMessage doesn't really return a ClonedIncomingMessage, it returns a PassThrough. But a PassThrough doesn't have a headers method. Forcing the type signature to unknown -> ClonedIncomingMessage seems to make the other methods that call this method also behave incorrectly. I'm still unclear what the best way is to fix it, but the issue seems to be in src/interceptors/ClientRequest/utils/cloneIncomingMessage.ts

Hey, folks. Thanks for elaborating on this.
I'll get to reproduce this in Node 16 when I have a minute.
Overall, the incoming message cloning is perhaps the most unstable part of this library. I couldn't find any good resources on how to do that, and the only approach I found was to split IncomingMessage into two PassThrough, which is precisely how it works at the moment.
Cloning headers may look like a viable solution for now, but I think it'd be much better to find a reliable way to clone IncomingMessage without having to manually add headers and other data potentially missing from PassThrough. I'd highly appreciate any input on this!
Also, the only reason we need to clone the incoming message is to be able to read it on the library's side and don't block the reading on the consumer's side. If we can't find a reliable way to clone incoming message, the last resort would be to drop the response body from the response event in the library, so that developers could read the body if they want by IncomingMessage reference (which would block any upstream reading still).

The IncomingMessage seems to use getter/setter with its own prototype.
https://github.com/nodejs/node/blob/master/lib/_http_incoming.js#L107
So currently implementation doesn't clone headers field because the cloneIncomingMessage clones only the instance properties.
I try to clone the IncomingMessage.prototype in my local environment and passes the failing tests.
However, it is a bit scary code.
  const stream = message.pipe(new PassThrough())

  const proto = {}
  for (const prop of [
    ...Object.getOwnPropertyNames(IncomingMessage.prototype),
    ...Object.getOwnPropertySymbols(IncomingMessage.prototype),
  ]) {
    console.log('IncomingMessage', prop);
    Object.defineProperty(proto, prop, {
      ...Object.getOwnPropertyDescriptor(IncomingMessage.prototype, prop),
    });
  }
  for (const prop of [
    ...Object.getOwnPropertyNames(PassThrough.prototype),
    ...Object.getOwnPropertySymbols(PassThrough.prototype),
  ]) {
    Object.defineProperty(proto, prop, {
      ...Object.getOwnPropertyDescriptor(PassThrough.prototype, prop),
    });
  }
  Object.setPrototypeOf(stream, proto);

That's a good observation, @hrsh7th. Then we can extract property descriptors from IncomingMessage and infer those when cloning. Do you think that'd work?
Object.getOwnPropertyDescriptors should return both plain properties and getter/setters (and Symbols).

The current implementation will clone properties defined in instance but not clone properties defined in prototype.
So I think we should add it. I'll make PR soon.

I've submitted the PR. I'm not an English speaker so I'm sorry. I'll talk about this via actual codes.

Awesome find. I tried cloning it with the clone npm library and it worked,
minus successfully adding the IS_CLONE property which broke a few other
things.
On Sat, Feb 26, 2022 at 5:25 AM hrsh7th @.***> wrote:

The current implementation will clone properties defined in instance but
not clone properties defined in prototype.
So I think we should add it. I'll make PR soon.
—
Reply to this email directly, view it on GitHub
https://github.com/mswjs/interceptors/issues/212#issuecomment-1052124074,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAAFACBL2KTG3PZ5BFEN7ZTU5DIFJANCNFSM5PKKVPVQ
.
Triage notifications on the go with GitHub Mobile for iOS
https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675
or Android
https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.
You are receiving this because you commented.Message ID:
@.***>

Oh. If we just want to clone (without using PassThrough), it's can use clone module, I think too.

#195 seems related
Also https://github.com/nodejs/node/issues/36550 could have valuable background info related to the lazy IncomingMessage.headers change (https://github.com/nodejs/node/pull/35281)


Theme Change of ToolBar

Hi, there. There might be a little problem of ToolBar cause when switching between differet themes, the border color of ToolBar doesn't change, remaining the default like this:

Anyway, it's no big deal. If you think it's a bother, please leave it alone.
Looking forward to your reply^^

Is it QMdiSubWindow?
It looks more like it rather than QToolBar

Oops, maybe I’m wrong. It’s Dockwidget.

OK, Now it should work. There was no style for QDockWidget in the first place, so i've added the style and appropriate icon.
That indeed change the style of the title bar of qdockwidget, but it is only for docked one. It doesn't change the undocked qdockwidget's title bar, according to the docs. They say
The style sheet has no effect when the [QDockWidget](https://doc.qt.io/qt-6/qdockwidget.html) is undocked
as Qt uses native top level windows when undocked.

So if you want to do it you need to declare the custom title bar and set that with setTitleBarWidget.

Ok, it works well for me. Thank you^^


Consider merging fregante/github-issue-link-status into refined github

Hello, I am following up on https://github.com/refined-github/refined-github/pull/7444 (which has been working great) and now wanting to do the same for https://github.com/fregante/github-issue-link-status (opened a PR here), but I noticed it's now owned by you as well.
Would it be possible to merge that feature into refined github, instead of maintaining two separate extension now?
Thanks for your consideration.

I would like to see this. Actual JS + CSS is ~200 lines and from my brief look we can almost cut that in half if moving into RGH.
Potential issues I see are two:

Rule 2: The feature once added will be very prominent, we need to decide whether it really makes sense for everyone.
Rule 6: Issue/PR links are common so it is likely going to trigger on every conversation page. Can it be slow or eat up quota quickly? (though the latter is less a concern unless you are browsing new pages at light speed).

Rule 2: fair consideration
Rule 6: that doesn't seem to change since I am already using the extension right now?

Rule 6: that doesn't seem to change since I am already using the extension right now?

Yeah it's not a blocker, just a reminder. We seldom worry about this kind of stuff but things do add up.

My concerns are:

that feature is too bright, we should not color the entire link but just add the icons. I wanted to add multiple styles to the extension for a long time
the feature adds an icon next to every link on the page, causing a layout shift (CLS). This should happen as early as possible to avoid causing that. Our observer could take care of that

I'm not particularly concerned about quota specifically because the feature would only work on GraphQL, which requires a token, which means our usage is wellll below the limits.

can almost cut that in half if moving into RGH.

You're right, with the observer and batched-function this is probably not that big. It should look something like:
observe(the selector, initLink);

function initLink(link) {
  link.append(PR or issue icon, depending on link.href)
  fetchInfo(link)
}

const fetchInfo = batchedFunction((links) => {
  // build query
  // query api
  // update links
});


NIFI-10651 Upgrade Iceberg transitive dependencies

Summary
NIFI-10651 Upgrades multiple transitive dependencies in Apache Iceberg components to align with current versions also defined for Apache Hive components. These transitive dependencies have various associated vulnerabilities and should be upgraded to align with versions in other Apache NiFi modules.
Tracking
Please complete the following tracking steps prior to pull request creation.
Issue Tracking

[X] Apache NiFi Jira issue created

Pull Request Tracking

[X] Pull Request title starts with Apache NiFi Jira issue number, such as NIFI-00000
[X] Pull Request commit message starts with Apache NiFi Jira issue number, as such NIFI-00000

Pull Request Formatting

[X] Pull Request based on current revision of the main branch
[X] Pull Request refers to a feature branch with one commit containing changes

Verification
Please indicate the verification steps performed prior to pull request creation.
Build

[X] Build completed using mvn clean install -P contrib-check

[X] JDK 8
[ ] JDK 11
[ ] JDK 17

Licensing

[ ] New dependencies are compatible with the Apache License 2.0 according to the License Policy
[ ] New dependencies are documented in applicable LICENSE and NOTICE files

Documentation

[ ] Documentation formatting appears as expected in rendered files

Hi @exceptionfactory, thanks for looking through the dependencies and correcting the vulnerable versions. My only question is that is it necessary to include dependencies like calcite or avatica since they are excluded and not present in the built bundles.

Thanks for the feedback @mark-bathori, good catch on the Calcite dependencies! I brought those other along with other Hive-related dependencies, but you are correct that they are not included. I will remove the Calcite and Avatica references.

+1 LGTM, thanks for the review @mark-bathori and thanks for the improvements @exceptionfactory ! Merging to main


Move to Project Scaffold + .Net 35 support

This PR does the above. You can build it using ./build.cmd or ./build.sh
You might need to make some changes to get this working on your CI server.

The tests seem to all pass on my side.  I can try and take a look over the weekend if I get some spare
minutes!
On 10 July 2015 at 12:23, varon<EMAIL_ADDRESS>wrote:

The tests seem to all pass on my side. It's probably a configuration issue:
Starting Target: RunTests (==> CopyBinaries)
C:\Work\github\aether\packages\NUnit.Runners\tools\nunit-console.exe "-nologo" "-noshadow" "-labels" "C:\Work\github\aet
her\tests\Aether.Tests\bin\Release\Aether.Tests.dll" "-xml:TestResults.xml"
C:\Work\github\aether\packages\NUnit.Runners\tools\nunit-console.exe "-nologo" "-noshadow" "-labels" "C:\Work\github\aet
her\tests\Aether.Tests\bin\Release\Aether.Tests.dll" "-xml:TestResults.xml"
ProcessModel: Default    DomainUsage: Single
Execution Runtime: net-3.5
***** Aether.Tests.Composition.isomorphism over partial return None when None
***** Aether.Tests.Composition.isomorphism over partial return value when Some
***** Aether.Tests.Composition.isomorphism over partial sets value when None
***** Aether.Tests.Composition.isomorphism over partial sets value when Some
***** Aether.Tests.Composition.multiple isomorphisms over partial return None when None
***** Aether.Tests.Composition.multiple isomorphisms over partial return value when Some
***** Aether.Tests.Composition.multiple isomorphisms over partial sets value when None
***** Aether.Tests.Composition.multiple isomorphisms over partial sets value when Some
***** Aether.Tests.Functions.Lens.get returns correct values
***** Aether.Tests.Functions.Lens.getPartial returns correct values
***** Aether.Tests.Functions.Lens.map modifies values correctly
***** Aether.Tests.Functions.Lens.mapPartial modifies values correctly
***** Aether.Tests.Functions.Lens.set sets value correctly
***** Aether.Tests.Functions.Lens.setPartial sets value correctly
Tests run: 14, Errors: 0, Failures: 0, Inconclusive: 0, Time: 0.305643749781216 seconds
Not run: 0, Invalid: 0, Ignored: 0, Skipped: 0
Finished Target: RunTests

Build Time Report
Target         Duration

Clean          00:00:00.0061609
AssemblyInfo   00:00:00.0104359
Build          00:00:00.4058076
Build-NET40    00:00:00.2471806
Build-NET35    00:00:00.2393580
CopyBinaries   00:00:00.0142938
RunTests       00:00:01.5252672
Total:         00:00:02.4732217
Status:        Ok
—
Reply to this email directly or view it on GitHub
https://github.com/xyncro/aether/pull/16#issuecomment-120388536.

@kolektiv Did you have manage to take a look at this yet?

I haven't had a chance to look I'm afraid, struggling to find many spare days for a week or so! Are you able to repro the problem elsewhere at all?

Apologies for not getting back to you here. I'm not able to reproduce the error from my side. A clean build produces valid output as I provided above.
Are you able to do so on your local machine, or is it an Appveyor specific problem?

@kolektiv Any luck?

Sorry, I'm travelling this week but I'll work this out and merge it when I get back, one way or another!

Thanks for the update! I look forward to it.

@kolektiv A gentle reminder that we're still waiting for this to get merged in. Hope the holiday was good.

@kolektiv I'm still waiting for your feedback. It's been over a month now, so please spend a few minutes to either merge or tell me what to fix here.

I'll take a look at this today and get something merged. Sorry, have had a few things going on outside of code for a few weeks, sadly!

@kolektiv,
I understand that your schedule has been busy, but it's time to face the facts on this PR.
I've been more than polite, accommodating and reasonable in dealing with your delays. This pull request was opened well over 2 months ago, and has yet to receive either resolution or a reason for rejection.
Given your handling of this issue, you've demonstrated a great degree of irresponsibility and negligence for a package maintainer.
To summarize where we stand:

All tests pass on my computer when run locally.
I cannot reproduce the build failure.
You refuse to merge because the CI build fails.
It's your responsibility to configure the CI server, OR advise me on how to fix it.
You have neither merged nor provided said advice.

I expect you to provide me with either advice on how to fix it, or alternatively resolve the issue yourself by the end of this week, otherwise I will consider this PR rejected.

Hi Varon,
Sorry this has taken much longer than I would like, you're right that it's
taken far longer than it should which is my fault. I'll get this looked at
ASAP and get back to you. Just to be clear, and making sure that the end
use is met - the main (only) goal is to have a NET35 version available as a
package?
Andrew
On 28 September 2015 at 11:34, varon<EMAIL_ADDRESS>wrote:

@kolektiv https://github.com/kolektiv,
I understand that your schedule has been busy, but it's time to face the
facts on this PR.
I've been more than polite, accommodating and reasonable in dealing with
your delays. This pull request was opened well over 2 months ago, and has
yet to receive either resolution or a reason for rejection.
Given your handling of this issue, you've demonstrated a great degree of
irresponsibility and negligence for a package maintainer.
To summarize where we stand:

All tests pass on my computer when run locally.
I cannot reproduce the build failure.
You refuse to merge because the CI build fails.
It's your responsibility to configure the CI server, OR advise me on
how to fix it.
You have neither merged nor provided said advice.

I expect you to provide me with either advice on how to fix it, or
alternatively resolve the issue yourself by the end of this week, otherwise
I will consider this PR rejected.
—
Reply to this email directly or view it on GitHub
https://github.com/xyncro/aether/pull/16#issuecomment-143703760.

This PR moves Aether to the F# project scaffold - https://github.com/fsprojects/ProjectScaffold, as a recommended standard for open F# projects.
A secondary goal is to add support for NET35, which is readily achievable on the new scaffold.

Presumably being on the scaffold project but not being NET35 compatible
would not be a goal though? I had assumed that the shift to project
scaffold was to support the NET35 requirement (while I don't mind going the
project scaffold route if it has significant pluses, if the goal is mainly
to support NET35 I think a lighter way to do so is possible).
On 28 September 2015 at 13:28, varon<EMAIL_ADDRESS>wrote:

This PR moves Aether to the F# project scaffold -
https://github.com/fsprojects/ProjectScaffold, as a recommended standard
for open F# projects.
A secondary goal is to add support for NET35, which is readily achievable
on the new scaffold.
—
Reply to this email directly or view it on GitHub
https://github.com/xyncro/aether/pull/16#issuecomment-143728898.

If I had to choose between the two, getting it on the project scaffold is more important.
You can see the advantages in the README for the scaffold project.

I've not used the fsprojects scaffold for other projects as a conscious choice (complexity, personal taste) and would only really want to adopt it if there was a specific requirement. I'm happy to release Aether as NET35 but I'm not sure that adopting the fsprojects scaffold just as "a good thing" is needed in that sense (the same build process as Aether is used for Freya, Chiron, Hekate, SemVer, without any issues at the moment). Would getting a NET35 build out soon (tomorrow) and following up with a scaffold review shortly after be OK for now? Presumably a NET35 build is required for another project?

From my side, I'd personally like a NET35 build. I don't particularly mind how it gets done, as long as there's a NuGet package I can reference as a dependency.
My eventual goal for Aether is to get lenses (and generated lenses) included in fsharp core, so my logic is that moving towards standards suggested by the Recommended Guidelines for F# Projects, Packages and Namespaces  should eventually help with this.
Ultimately, all I can do is motivate the change; as you are the maintainer of this project, the decision on whether or not to use the scaffold is ultimately up to you. Your decision, whichever it might be, is something I'll have to live with.
Thanks for providing clear and prompt responses so far.

Hi Varon,
I'll investigate more on the scaffold change now, although I think it may be overkill for Aether. I've just pushed a 7.0 to NuGet which is NET35, and also updates the common lenses included to the lens_ naming convention (just FYI if you're using any!). Hopefully this makes Aether more generally useful for you.
Sorry it's been a slog with this - I've been pretty burnt out and snowed under lately. No excuse I know, but apologies, not the kind of process I normally try and run.

Given Aether's progression since this was submitted, I think we can safely drop this PR at this stage, unless you feel extremely inclined towards archaeology.

Hah, fair enough - hopefully Aether and the changes have worked for you? I've been keen to maintain the net35 support for those who need it! I hope the later Aether iterations have made things neater for people too...

At present I'm no longer using .Net35 for any of my projects. It may turn out that I need it later, so keeping support for it is appreciated.

Cool. I'll be keeping things as low on requirements as possible, so it'll be staying until there's a good reason to remove it!


fixed invalid limit param; fix bug 698548

r- This is the right direction, but instead of try/catch in the view, add the limit parameter to the Form class. Then we'll be good!


heroic: Add optional Wine dependencies

Description of changes
Add optional Wine dependencies following a guide that is strongly recommended by upstream: https://github.com/lutris/docs/blob/master/WineDependencies.md
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

[x] 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
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 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.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1517


Typo in updateProgress() ?

Hope this is a typo. Please merge if so. or else just ignore this request.

This change has been merged into v1.1, thanks for your contribution.


shell: Add new API for adding subcommands

Added macro SHELL_SUBCMD_SET_CREATE which creates a set of subcommands.
SHELL_SUBCMD_ADD and SHELL_SUBCMD_COND_ADD can be used from any file to
add command to the set. This approach allows to have subcommands added
from multiple files.
Solution is using sorted memory section to which subcommands are added. When set is created an empty command is added and because of sorting all commands in the section follows the empty command. Shell is creating an empty entry which is always at the end of the section so that every set of commands is terminated by empty entry of the new command or this global terminator.
Additionally, added dedicated memory section for dynamic subcommands. This allow to change how dynamic commands are distinguished from static one. It is now done based on the address check. Previously it was done by using additional flag.
Added test and extended sample.

Failing CI fails on main branch as well. Created issue: #44544

@nordic-krch please rebase


Fix typo for Copy-GPO.MD

PR Summary
Fixing a typo where a period was used instead of space between "session" and "a".
PR Checklist

[x] Descriptive Title: This PR's title is a synopsis of the changes it proposes.
[x] Summary: This PR's summary describes the scope and intent of the change.
[x] Contributor's Guide: I have read the [contributors guide][contrib].
[x] Style: This PR adheres to the [style guide][style].

@tiburd
PR has been copyedited and is ready for final review, could you please check and merge? Thanks!

close > reopend


Install CockroachDB Doc Update

Re: Install CockroachDB
Issue Description
Do we really need step 3?
We currently have a third step to the install: "Make sure the CockroachDB executable works" -- how often does this not work? and if it didnt work from here we don't have any other next steps to fix it. I'm thinking we can cut this step and make the third step the add to the email list one. At least AB test having 3 steps instead of 4.
Suggested Resolution

cc @dianasaur323 @kuanluo @jess-edwards

A more user-friendly solution than removing the step would be to write troubleshooting guides to help users with bungled installation. I have seen a large number of students at Hackathons and at the Local:Host events that only realized the installation "didn't work" when running cockroach version.

OK -- I guess what I'm saying is right now that step isnt actionable

@sploiselle, do you remember any details about why installation didn't work for those large number of students at the Hackathons? We rarely (if ever) get such feedback on community channels, and this page gets very few negative feedback submissions, so that detail is a bit surprising to me.

@nstewart & @sploiselle
Backing up a little bit to bring full context:
The notion of altering / improving the install page came to light (not for the first time) when Nate said that for all the times he's visited the install page, he did not know there was a lead collection form on it.
The problem: Only 6% of downloaders give us an email address.
Observation / Proposition 1: The lead collection form appears below the fold. With the install instructions as simple as they, scrolling below the fold may no longer be necessary for many/most developers. Can the form be moved above the fold?
Observation / Proposition 2: The lead collection form blends into the rest of the page. Can it be designed to be more attention-getting?
Observation / Proposition 3 (and what I think Nate was suggesting in the original post): Are all of the instructions necessary now that install has been simplified? Can any instructions be removed?

Thanks for the context, @jess-edwards. Our instructions are pretty streamlined right now. We could do things like remove the callout about other versions being available to move content up the page. But really, the OS buttons at the top and then the install method tabs below those are pushing the content down the page. I don't think that's a problem in terms of the instructional content, but I can understand that having the signup far down isn't ideal.
Can I ask? Is this page one of the more important touch points for getting users to sign up? Do we get more signups on our release notes?

I think the fundamental issue here is that we need to capture more emails in order to better understand our user funnel. Although the way our installation page is designed is great from a docs perspective, we may have to add some marketing flair. Offering up a strawman proposal - perhaps it's time to consider moving install out of docs?

+1 @dianasaur323! -- I think it's a bigger discussion that we should move out of this ticket (and I know @jess-edwards is thinking about this), but I think we should take a look at whatever the industry standard is and use that as a starting point. A cursory glance at a few other databases suggests download does indeed live outside of docs.

Yes, would be great to look at what others do. At a glance, I'm seeing that projects that are NOT open source tend to have a separate download page with a gating step. Examples:

VoltDB: https://www.voltdb.com/try-voltdb/
MemSQL: http://www.memsql.com/download/

Mongo takes a different approach, where there's a Download Center (partially gated) as well as installation docs.
My instinct is that it is a bad idea to move this page away from all the rest of the content for which it is a prerequisite.

+1 to Jesse's point on Install is currently the pre-req, and regardless of where the download lives, there are many opportunities to make the email collection a lot more obvious and appealing.
We should try those improvements and get the email signup numbers up (or see if they will) before moving download away from docs, which is a BIG change.

On Sep 28, 2017, at 22:21, Jesse Seldess<EMAIL_ADDRESS>wrote:
Yes, would be great to look at what others do. At a glance, I'm seeing that projects that are NOT open source tend to have a separate download page with a gating step. Examples:
VoltDB: https://www.voltdb.com/try-voltdb/
MemSQL: http://www.memsql.com/download/
Mongo takes a different approach, where there's a Download Center (partially gated) as well as installation docs.
My instinct is that it is a bad idea to move this page away from all the rest of the content for which it is a prerequisite.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@nstewart, if this conversation is continuing elsewhere, can you update this ticket with details or just let me know. Also, we need to focus this ticket back to something actionable. How about I repurpose this to track that fact that where we tell users "confirm the binary" (not only on this page), we eventually need some follow-up guidance in case of problems.

@jseldess @nstewart I retract my position; the terminal-centric install docs totally alleviate the problem I was thinking of. I'm +1 on removing cockroach version if it achieve's PDM's vision.

Ok, I'll remove the cockroach version step from this page to at least inch the sign-up form up a bit. I think that it still adds value, in many situations, to have the user confirm the version of the binary just installed, though.


Interactive output format

Issue #, if available:
Description of changes:
Implemented a new CLI output format using the bubble tea tui. The new format includes a table with the same columns as the table-wide format and can be accessed through the table-interactive flag. The table can be resized both vertically and horizontally through resizing the terminal window and it supports vertical and horizontal scrolling.
The new output format lives in /selector/outputs/bubbletea.go.
The following bubble tea component was used to build the table: https://github.com/Evertras/bubble-table
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
https://user-images.githubusercontent.com/68402662/181605909-861086eb-a5b3-4be7-aecc-73beee6e4615.mov

NEAT!

Remember to hydrate the pricing caches w/ interactive mode just like with table-wide mode.   Currently, if you clear your cache (--cache-ttl=0) and then run w/ interactive mode, all prices show -Not Fetched-

Just one comment on the column sizes and after that, lgtm! Nice job! I'll leave it to @AustinSiu for the final review, but no need to hold-up on my account.


Custom serialization

:warning: Please install the  to ensure uploads and comments are reliably processed by Codecov.
Codecov Report
Attention: Patch coverage is 97.56098% with 1 line in your changes missing coverage. Please review.

Project coverage is 96.77%. Comparing base (0b7b2e8) to head (64cc49d).

Files with missing lines
Patch %
Lines

redis_dict.py
97.56%
1 Missing :warning:

:exclamation: Your organization needs to install the Codecov GitHub app to enable full functionality.
Additional details and impacted files
@@                  Coverage Diff                   @@
##           v2.6.0-pre-release      #56      +/-   ##
======================================================
+ Coverage               96.15%   96.77%   +0.62%
======================================================
  Files                       1        1
  Lines                     208      217       +9
======================================================
+ Hits                      200      210      +10
+ Misses                      8        7       -1

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


Only check for multiple CLI once a day

WHY are these changes introduced?
Fixes #0000

WHAT is this pull request doing?

How to test your changes?

Post-release steps

Measuring impact
How do we know this change was effective? Please choose one:

[ ] n/a - this doesn't need measurement, e.g. a linting rule or a bug-fix
[ ] Existing analytics will cater for this addition
[ ] PR includes analytics changes to measure impact

Checklist

[ ] I've considered possible cross-platform impacts (Mac, Linux, Windows)
[ ] I've considered possible documentation changes

#4999  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


Create jobs with generated names and add labels

When applying jobs for configuring or reindexing Dataverse, using a static name leads to conflicts, when the former job has not been deleted.
Changing the metadata to generate a unique name for us will solve that.
Cleaning up jobs is still a leftover to the K8s admin or tooling. This is made easier when adding proper metadata labels to all jobs with sth. like dataverse and/or dataverse-job.

Thx to @bronger for pointing out the issue with the missing labels :+1:


Simplified authentication

Simplified because the policy_id of the auth tokens does not change.

Looks good to merge @george-orcfax - just one small thing, can you shorten the commit message to match the format title: 50 chars; body: 72 chars? (you'll need to git amend and git push -f) we'll try and keep that consistency across the projects. There's a little more here: https://github.com/orcfax/code-review/tree/7481311df0e0d64167d0d994300352bb0e79ae20#code-commits

Shortened the commit message.


v0.10.0

I'm guessing #172 would be the only PR that is left for this release? But it seems like the author has abandoned it quite some time ago so we might as well go for it.

It would be a nice thing if we would finally fix all these clippy lints from our CI though, they always clutter the diffs a ton.

+1 from me. We should elevate clippy warnings to errors and force them to be fixed through CI in the future. If you really don't want a check, you can reason why and add a #[cfg()] instead to disable the check at that point.
Other than that, the release sounds good to me. I've been working off master for quite some time without issue.

If we don't want to tackle this in this PR I'd approve as well...do we?

That definitely sounds like a much bigger separate PR to me...
On Wed, Jul 21, 2021, 2:59 PM Henrik Böving @.***>
wrote:

If we don't want to tackle this in this PR I'd approve as well...do we?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/stm32-rs/stm32h7xx-hal/pull/233#issuecomment-884459171,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAUS5FOXRFB3Z3PBZ7NLMDDTY4RIVANCNFSM5AWUO67A
.

I definitely agree with keeping the clippy warnings under control! #224 removed a few, and #225 will tackle some more. In fact, I only left #225 unmerged so that we could have one last release on the old MSRV, otherwise it's ready for review.
Anyhow I'll make the release now, thanks all!


"Reserved Slots.txt" should be "ReservedSlots.txt" or "reserved_slots.txt" to match directory

The naming convention for the ~/.config/SCP\ Secret\ Laboratory/ folder is either snake case as seen with config_gameplay.txt and config_remoteadmin.txt, or PascalCase with SteamIdBans.txt and IpBans.txt1. Reserved\ Slots.txt` matches the directory name, but otherwise sticks out like an eyesore in the directory listing.
~/.config/SCP Secret Laboratory$ ls
 AddBan.sh                    config_remoteadmin.txt   IpBans.txt       PrintBans.sh          SteamIdBans.txt        verkey.txt.old
 config_gameplay_backup.txt   internal                 keybinding.txt  'Reserved Slots.txt'   SteamIDWhitelist.txt
 config_gameplay.txt          IpBans1.txt              mutes.txt        ServerLogs            verkey.txt`

But most importantly, it's because spaces are a complete pain to type in Linux. We already had to force people to change dedicated_slots to reserved_slots in their configs. Smod could read from Reserved\ Slots.txt but write to ReservedSlots.txt, reserved_slots.txt, or even config_reservedslots.txt (to match other configuration files) for backwards compatibility, and then eventually make the switch to the new file.

This is a good example of a hiccup caused by the space. It makes creating programming tools around the config folder more difficult.
https://stackoverflow.com/questions/52508887/how-do-i-define-a-gitattributes-rule-for-a-file-with-spaces-in-it?noredirect=1

Maybe even make the configs .yml files? I want dat automatic syntax highlighting.

Done for main game and ServerMod, whichever updates next will have this change.

Thank you so much!!!


FixedVirtualAccount.create()

get exception : com.xendit.exception.ApiException: There was an error with the format submitted to the server.
with this calling : FixedVirtualAccount.createClosed("LZZGWG", BankCode.BCA.text, "PT. TARGET SUKSES SINERGI", 1200000)

Hi @alviansyahexza, your name param is invalid. It must satisfy this regex /^[a-zA-Z0-9\\s?]+$/
Please consider removing .


♻ Move ConsumerForm to its own LiveView

#761  👈 (View in Graphite)
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


add(GINTC): Descriptions about VIP, PIP and HC Fields

You may find related fields in MIPS virtualization. These fields are their LoongArch counterparts with the same name but different arrangement in sizes and locations.

Thanks, links added to MIPS spec.


Exodus failing because one of the jar doesn't have pom in it

The error message is:
===== Please double check that you have no typos.
if you REALLY meant to reference this jar and you know it exists even though there IS NO pom,
please rerun the tool with --ignoreMissingDependencies flag at the end =====
I have verified the jar exists but the pom is not in the jar.
Can anyone please help me.

@or-shachar is this an error from AetherResolver?
Following our conversation - another example why Exodus should move away from Aether to something else...
In the meantime why do we have ignoreMissingDependencies = false here

@natansil Is there any workaround for this? I tried adding a dummy pom but it get's stuck on it.
Is there any specific field it expects?

4.0.0
com.google.apis
google-api-services-cloudcommerceprocurement
v1-rev20190531-1.25.0-SNAPSHOT

I'm not sure it would help, but can you try and change this line:
https://github.com/wix/exodus/blob/master/dependency-resolver/maven-dependency-resolver/src/main/scala/com/wixpress/build/maven/AetherMavenDependencyResolver.scala#L62
withSession(ignoreMissingDependencies = false => withSession(ignoreMissingDependencies = true
re-build and run?

Thanks. Will try this.

One of the dependencies we use didn't have pom.xml and it was failing because of that. The change suggested by @natansil works.


Feat/2515 full application submitted

What's included?
closes #2515
Who should test?
✅ Product owner
✅ Developers
✅ UTG
How to test?

Staged exercises with open application after 18/06/2024 can see the new full application submitted status

Go to the preview link: https://jac-admin-develop--pr2602-feat-2515-full-appli-k7d3ccp6.web.app/exercise/tzGyKNa4SakZ0CS8241V/stages/selection
Submit the application of the exercise: https://jac-apply-develop--pr1258-feat-2515-full-appli-x7vkvrfi.web.app/vacancy/tzGyKNa4SakZ0CS8241V/

Sign in<EMAIL_ADDRESS>1qazZAQ!1qaz

The application should be set to Full Application Submitted status
Set the application back to Full Application Not Submitted, it should move back to shortlisting
Click Set status button, it should include the new  Full Application Submitted status.
Click Show filters, it should include the new  Full Application Submitted status.
System should sent Full Application Submitted email to notify the candidate.

https://github.com/user-attachments/assets/a58f97f4-dea5-466c-ad30-023a196b5fa6

Staged exercises with open application before 18/06/2024 will not apply the new full application submitted status

Go to the preview link: https://jac-admin-develop--pr2602-feat-2515-full-appli-k7d3ccp6.web.app/exercise/HD0kFoyONlPYSIwOH3tA/stages/selection
Submit the application of the exercise: https://jac-apply-develop--pr1258-feat-2515-full-appli-x7vkvrfi.web.app/vacancy/HD0kFoyONlPYSIwOH3tA/

Sign in with:

<EMAIL_ADDRESS>1qazZAQ!1qaz

The application should use the original Shortlisting Passed status.
Click Set status button, it should not include the new  Full Application Submitted status.
Click Show filters, it should not include the new  Full Application Submitted status.

https://github.com/user-attachments/assets/21daa0d8-71a9-41a4-9ed8-2ad8efdd54c0
Risk - how likely is this to impact other areas?
🟠 Medium risk - this does change code that is shared with other areas
Additional context
Include screen grabs, video demo, notes etc.
Related permissions
Have permissions been considered for this functionality?

No permission changes required
Permissions have been added / updated. Details:

PREVIEW:DEVELOP
can be OFF, DEVELOP or STAGING

https://jac-apply-develop--pr1258-feat-2515-full-appli-x7vkvrfi.web.app/vacancy/tzGyKNa4SakZ0CS8241V/

@nickaddy

The preview link has been updated for skipping email verification of dummy accounts: https://jac-apply-develop--pr1258-feat-2515-full-appli-x7vkvrfi.web.app/vacancy/tzGyKNa4SakZ0CS8241V/

The count would update in background, but it may take several minutes for updating. So, if you check it after a while, the count would update.

If candidate submit second stage application, the status will update to 'Full application submitted'. This has been implemented on Apply site and DP.


insert U.S. flag on U.S. information page

Self-explanatory. Please hold on doing so until we have the logo from @little-wow so we can figure out placement of both.

Please assign me this issue. thank you.


Capture all unknown errors in backend to send to the log

This is how the frontend error boundary currently logs all uncaught/unknown errors:
https://github.com/joulev/ezkomment/blob/7733127c737a04beda6faace5961a42aaaef69a5/client/layouts/errors.tsx#L55-L69
The /api/error route is there and you can use it to log all uncaught errors on the backend too. The Vercel deployment already has all necessary environment variables.
I will check the log once every day (or every two days) and will notify if any anomalies occur.

I will delete the /api/error endpoint, it should be converted to a utility.
next-connect's configurations have an onError property, I will use that to log the uncaught errors.

No, /api/error is used to send a request to the Axiom dataset. I do not want to expose that Axiom URL and API key to the client side, so an API route is necessary. It’s called URL masking.
Instead you may change it to a function, then call that function inside /api/error and your onError.

No, /api/error is used to send a request to the Axiom dataset. I do not want to expose that Axiom URL and API key to the client-side, so an API route is necessary. It’s called URL masking.

Hmm, similar to Proxy? Okay, I will keep the endpoint.

Errors so far.
Might be a good idea to (1) only send errors to the log in production mode and (2) log more details (to identify the source of the error, where it went wrong, etc. easier).

(1) only send errors to the log in production mode and (2) log more details (to identify the source of the error, where it went wrong, etc. easier).

I have changed the code so that it only send errors to the log in production mode – it is not very hard. For (2) I will send the errors' stack trace together with their message as well.
Some specific errors will be catched and handled appropriately, for example: if a user or record is not found then the error will be catched and 404 status code will be sent back. Other errors will not be catched and will be logged.
But Firebase lacks documentation for the errors that could happen when dealing with Firestore and Firebase Storage. And I cannot access Firebase errors' types information – making the implementation much harder.
And why the hell does JS/TS allow anything to be thrown instead of only allowing Error and its subclass to be thrown?


Video on demand and linear VPAID does not work on iOS Safari

VAST/VPAID linear ads does not work in combination with plain VOD MP4 file. This seems to be related with how Safari deals with programmatic .play() invocation on Safari. There is currently no known fix to this issue.

@Addvilz - Is the issue still reproducible?

@Addvilz - Can you please confirm if the issue resolved or does it still exist ?

@HariPriyaKuberSingh unless you have fixed it, it probably does :)

@Addvilz a fix for this issue has been pushed. If this fixes your problem, could you confirm and close this ticket? Thanks!

@Addvilz Can you close this issue?

@Addvilz Closing the ticket since as mentioned on Sep 7 2023, a fix for this issue was released! Thank you


[YUNIKORN-143] Travis CI integration for K8shim

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@0f2c95c). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master     #110   +/-   ##
=========================================
  Coverage          ?   54.78%
=========================================
  Files             ?       29
  Lines             ?     2811
  Branches          ?        0
=========================================
  Hits              ?     1540
  Misses            ?     1213
  Partials          ?       58

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 0f2c95c...f6ea5da. Read the comment docs.


Crash before loading the game (fabric 1.20.4)

Hello,
sadly I got issues with your mod. Installing and running the mod for the first, starts and working correctly. After closing the game and trying to restart, it crashes the game, before it even starts it.
I'm pasting the crashlog below.
crash-2024-02-09_18.26.42-client.txt

Unable to reproduce, with the steps mentioned.
Could  you provide your menu.json, found in the minemenu folder?

Sure
menu.json

Your menu.json is for sure broken. What exactly is causing it, I´m not quite sure.


Remove unnecessary checks from the Update REST API

Describe the bug
Update REST API did a lot of checking in the Flask app that wasn't needed because those checks and all in the deserialize() method of the model which was never called. Therefore, we need to remove these checks and use the deserialize method instead.

Closing because duplicate of #34


Huge memory allocations

I've just hit an unfortunate situation where OOIPy blows up RAM usage when getting one second of data.
Minimal reproducible example:
import datetime

from ooipy.request import hydrophone_request

start_time_str = "2021-09-19T12-16-49"
end_time_str = "2021-09-19T12-16-50"
node = "PC01A"

start_time = datetime.datetime.strptime(start_time_str, "%Y-%m-%dT%H-%M-%S")
end_time = datetime.datetime.strptime(end_time_str, "%Y-%m-%dT%H-%M-%S")

hydrophone_data = hydrophone_request.get_acoustic_data(
    start_time, end_time, node, verbose=True
)

In Google Colab I see ~10GB allocation and then one more ~10GB which crashes the kernel.

The same thing crashed our processing in GitHub VMs.
Here's why I narrowed it down to just one second of data:

I think that this issue is caused by how data is organized from OOI's side of things. They have actually since fixed each mseed file to be 5 minutes (and they are doing some type of gap filling).
I'm closing this for now.


Draft: ReactiveVaultTemplate for the key-value backend version 2

What is done:

Add version 2 (by porting blocking code APIs)
Unit tests for all additional classes
Maybe some code deduplication and cleanup
A second round of editing java docs
Using WebClient to do all object conversion
Created data object to represent the v2 nested data

Questions I have:

Is author attribution correct since this can be considered a port of the block code?
Overall, what do you think about the change?

What I am looking at:

Java docs
Code deduplication and static analysis
Cleaning up the diff

I am available for video chat.

@mp911de - I had a bad git config when doing most of the work on this. After we finish review, would it be possible for me to re-make the branch so that the commits look correct?

Sure. A force-push is fine.
Am 26. Aug. 2023, 01:10 +0200 schrieb Timothy R. Weiand @.***>:

@mp911de - I had a bad git config when doing most of the work on this. After we finish review, would it be possible for me to re-make the branch so that the commits look correct?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.Message ID: @.***>

Force pushed the branch with the correct email for me. I have 2 questions buried in the comments. Thanks for the help!


tag based code injection does not work

Issue Summary
Setting code injection on tags does not work. This affects headers as well as footer tags. Global or post based code injection works as expected.
To Reproduce

Create a new tag
Add code injection (header or footer)
Refresh post

Any other info e.g. Why do you consider this to be a bug? What did you expect to happen instead?
Technical details:

Ghost Version: 3.37
Node Version: 6.14.8
Browser/OS: chrome
Database: mysql

Hey @danielnachtrub 👋  Tag-based code injection is only intended to work on the tag index page, rather than on individual posts with the tag applied. You'd need to handle this in the theme if you'd like to inject code to a post based on the tags applied.


Update UG - addtask

Currently, our UG has no description on addtask. Let's add the description of addtask, showing its format and examples for users to understand how to use it properly. The command summary has also been updated for visual clarity.

Codecov Report
Base: 72.48% // Head: 72.48% // No change to project coverage :thumbsup:

Coverage data is based on head (08f7b45) compared to base (179813a).
Patch has no changes to coverable lines.

Additional details and impacted files
@@            Coverage Diff            @@
##             master     #130   +/-   ##
=========================================
  Coverage     72.48%   72.48%
  Complexity      574      574
=========================================
  Files            98       98
  Lines          1788     1788
  Branches        189      189
=========================================
  Hits           1296     1296
  Misses          440      440
  Partials         52       52

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Issues deploying to Elastic Beanstalk with Yarn

I have used React on Rails several times and really appreciate it.  Thanks for all your work.   Historically, it would just deploy to AWS Elastic Beanstalk without issues.   However, with the switch to Yarn, which is not installed on the AWS linux image, it no longer does.
I tried changing the config.npm_build_production_command, but that did not resolve the issue.  In addition, I felt it was better to use the same package manager in dev and production.
After much fiddling around, I found that adding a yarn.config file in the .ebextensions folder resolved the issue:
commands:

  01_node_get:
    # run this command from /tmp directory
    cwd: /tmp
    # flag -y for no-interaction installation
    command: 'sudo curl --silent --location https://rpm.nodesource.com/setup_6.x | sudo bash -'

  02_node_install:
    # run this command from /tmp directory
    cwd: /tmp
    command: 'sudo yum -y install nodejs'

  03_yarn_get:
    # run this command from /tmp directory
    cwd: /tmp
    # don't run the command if yarn is already installed (file /usr/bin/yarn exists)
    test: '[ ! -f /usr/bin/yarn ] && echo "yarn not installed"'
    command: 'sudo wget https://dl.yarnpkg.com/rpm/yarn.repo -O /etc/yum.repos.d/yarn.repo'

  04_yarn_install:
    # run this command from /tmp directory
    cwd: /tmp
    test: '[ ! -f /usr/bin/yarn ] && echo "yarn not installed"'
    command: 'sudo yum -y install yarn'

I am certain there is some better, more concise way to achieve this, but I not an AWS expert.  This worked for me.
Anyway, I thought it might be worth documenting here, in case other people are trying to deploy a react-on-rails app to Elastic Beanstalk.
Thanks for all your efforts!  React on Rails was the first framework that enabled me to achieve really good results with a javascript/client-side app.

Yes, I will do this this week.  Thanks.

@chrisjones-tripletri Did you get a chance to doc this? I'd like to get this issue closed. Thanks!

Sorry this took so long.   I have actually never done a pull request before, and I didn't know how, so I had to research it.   I just submitted "Adding Documentation About Deploying to Elastic Beanstalk with Yarn #790".  Hopefully I did it correctly enough.  I am not sure I did it in a way that links back to this bug.


Scrap Mechanic: Game fails to launch with DXVK but works with WineD3D11

Software information
Name:
Scrap Mechanic
Rendering API:
DirectX 11
Steam page:
https://store.steampowered.com/app/387990/Scrap_Mechanic/
What should happen:
Game launches as normal.
Note: The game does launch when using WineD3D11 via proton setting! But it's flawed with minor graphical glitches like missing transparency in glass etc or broken dynamic lights and bad performance.
What actually happen:
Game launches, shows black screen & crashes seconds later.
Additional notes:
It looks like the problem exists between the mygui library and dxvk, so I looked up the source code the game log refers to and found this on github:
Line from the mygui.log:
00:39:29  |  Platform  |  Critical  |  RenderManager 0 viewport sets  |  z:\deps\vc141\mygui\platforms\directx11\directx11platform\src\mygui_directx11rendermanager.cpp  |  130
Github link with the cpp:
https://github.com/MyGUI/mygui/blob/master/Platforms/DirectX11/DirectX11Platform/src/MyGUI_DirectX11RenderManager.cpp
Maybe this helps to determine the problem.
Also this issue is reported by almost everyone on ProtonDB:
https://www.protondb.com/app/387990
Log files
d3d11 log:
https://gist.github.com/MadByteDE/49d07ba90fdd6189b25eb5580d6043b0
dxgi.log:
https://gist.github.com/MadByteDE/ca161ff7d09c257e62ebccc7677922d8
Proton log:
https://gist.github.com/MadByteDE/7670a761b41fb53ec3d817c0231ab922
Log created by the game itself:
https://gist.github.com/MadByteDE/f393bb5f24e2cdd0996412b8dcc28847
System information
Proton version: 4.2-9
DXVK version: 1.2.1 (But 1.2.3 doesn't work as well - I tested it)
Processor Information:
CPU Vendor:  AuthenticAMD
CPU Brand:  AMD Ryzen 5 1600 Six-Core Processor
Operating System Version:
"Manjaro Linux" (64 bit)
Kernel Name:  Linux
Kernel Version:  4.19.56-1-MANJARO
X Server Vendor:  The X.Org Foundation
X Server Release:  12005000
X Window Manager:  GNOME Shell
Steam Runtime Version:  jenkins-steam-runtime-beta-release_0.20190320.2
Video Card:
Driver:  NVIDIA Corporation GeForce GTX 1060 6GB/PCIe/SSE2
Driver Version:  4.6.0 NVIDIA 430.26
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 60 Hz
VendorID:  0x10de
DeviceID:  0x1c03
Revision Not Detected
Number of Monitors:  1
Number of Logical Video Cards:  1
Primary Display Resolution:  1920 x 1080
Desktop Resolution: 1920 x 1080
Primary Display Size: 20.91" x 11.73" (23.94" diag)
53.1cm x 29.8cm (60.8cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 6144 MB
Supported MSAA Modes:  2x 4x 8x 16x
Memory:
RAM:  16036 Mb

I can confirm that the game doesn't crash anymore with the fix (commit #1117 by K0bin).
btw I experience a performance boost by +100FPS in most situations in the game compared to WineD3D. Also the visual glitches are fixed. You guys are awesome.

For AMD GPU looks this issue still not fixed.
steam-387990.log

Your logs say 1.3-2 which doesn't contain the fix.

Your logs say 1.3-2 which doesn't contain the fix.

Maybe I have misunderstood the changelogs of 1.3 version, but the last string said that Scrap Mechanic: Fixed crash caused by incorrect RSGetViewport behavior. I just retested and see that the game still crashes.

Oh my bad, I think I swapped the numbers in my head.
Either way, please make an apitrace.

Either way, please make an apitrace.

ScrapMechanic_dxgi.log
ScrapMechanic_d3d11.log

@NTMan that is not an apitrace, those are DXVK log files.
Also, please test whether the game works for you without ACO.

Also please post the game's own log file.
Maybe @MadByteDE can tell you where those are stored.

The game logs can be found in /path_to_steam_apps/common/Scrap Mechanic/Logs/

@NTMan that is not an apitrace, those are DXVK log files.

I used your instruction file ScrapMechanic.trace does not exist after the game crash.

Also, please test whether the game works for you without ACO and test PROTON_FORCE_LARGE_ADDRESS_AWARE=1. You're quite obviously running into a different issue here since the root cause for the crashes has been fixed (and you also seem to have a Vulkan driver set up).

My launch option is PROTON_FORCE_LARGE_ADDRESS_AWARE=1 DXVK_HUD=full RADV_PERFTEST=llvm PROTON_LOG=1 %command% from last launch.

Also please post the game's own log file.

game-20190715-103834.log

There are a lot of erros about missing shader files in there. (It ships it's own D3DCompiler though so that should work).
Try validating the game files with Steam.

Try validating the game files with Steam.

Steam said that all fine.

I used your instruction file ScrapMechanic.trace does not exist after the game crash.

For me, it is not at all obvious that after adding the d3d11.dll, dxgi.dll, dxgitrace.dll files, the trace file will appear not in the game directory but in ~/.steam/steam/steamapps/compatdata/<Steam game ID>/pfx/drive_c/users/steamuser/Desktop.
Why it is not written anywhere?
ScrapMechanic.trace

You made your trace with DXVK. Looks like I also need a WineD3D trace to compare.

@NTMan Have you tried to delete/rename the "Shaders" folder from "/Scrap Mechanic/Cache/" ?
The game will re-generate the files on game launch if it works correctly. It takes about 1-2minutes (blackscreen after launching the game is normal). Not sure if this will change anything, but might be worth a try.

@NTMan Have you tried to delete/rename the "Shaders" folder from "/Scrap Mechanic/Cache/" ?
The game will re-generate the files on game launch if it works correctly. It takes about 1-2minutes (blackscreen after launching the game is normal). Not sure if this will change anything, but might be worth a try.
I tried deleting the whole Cache folder myself & it has been re-generated by the game it seems.
Sometimes the game rendered too small after doing so, but it was fixed when I pressed "Apply" in the graphics options.

Very very interesting the game was launched successfully after removing "Shaders" folder, but after the second run without removing "Shaders" folder always crashes again. So for working "Shaders" folder should be removed every time before the next launch. I don't think that this is normal.

Then you should look at the games log file again and see what fails. Maybe you need to delete the whole cache folder for it to work properly ? :/

Maybe you need to delete the whole cache folder for it to work? Maybe the shaders need some other cache files to be re-generated too.

Finally, I removed the whole folder "Cache", but this helps again only one time (only on the next run) The second attempt running the game without removing "Shaders" folder leads to 100% crash.

TL:DR
I would try to uninstall the game completely and then reinstall it. Make sure to remove the prefix as well. Here is what I think:
The last error you get from the game is:
base_light.h(148,23-59): error X3004: undeclared identifier 'LinearSampleCC'
The warning before that error is:
10:38:35 (1) WARNING: d:\jenkinsworkspace\scrapmechanic\contraptioncommon\renderer\dx11\d3d11_device.cpp:927 Shader cache miss, failed to open dependency for: '$GAME_DATA/Shaders/hlsl/instanced_object_parts.hlsl' EntryName: 'visualizationColor' CacheName:'../Cache/Shaders/Release/instanced_object_partsvisualizationColorPSENV_MAP3.sco' Dependency: '$GAME_DATA/Shaders/hlsl/base_texture.h'
When searching the header files for that variable I get this:

It shows that the variable gets declared in the file which previously couldn't be loaded by the game.
I would ask myself now - why was the game unable to load the files? I don't think DXVK has anything to do with this error, because when you delete the shaders folder the game runs, maybe because it doesn't load the files from the HDD but instead generates it and then directly uses them. Sounds to me like a Wine / Library / Installation problem of some sort.
Have downloaded a fresh version of the game or do you use an old install (in which you might already tried various stuff to get the game running like installing dll's via winetricks)? Maybe try to do a fresh install and then see what happens. Sorry if this won't work ;)

I would try to uninstall the game completely and then reinstall it. Make sure to remove the prefix as well.

Unfortunately reinstalling the game with completely removing prefix didn't help.