Anti-Aliasing / Anisotropic Filtering

Now that I got DXVK running (with very smooth results, big thumbs up for the great work!), I see that games look like they do no anti-aliasing (or maybe not at the full potential), and also I see a lot of aliasing in textures when looking at them from certain angles which may either be a result of different bias for mipmap, or missing anisotropic filtering (or trilinear filtering).
Are these features already fully handled by DXVK?

Anything related to texture filtering and MSAA should be fully supported by DXVK, yes.
Can you name a game where you see issues, post a screenshot or something, and post your hardware, driver versions etc.?

It's most visible in Witcher 3 which looks different. I cannot really describe it: More crisp? It looks different than vanilla wine. Maybe DXVK supports features that vanilla does not and that's why.
Wolfenstein New Order seems to have texture aliasing like there's no anisotropic filtering. But I'd need to cross-confirm this with vanilla. I didn't start it in a while. I'm not even sure if it really uses DXVK because it may not be a DX11 game.
Skyrim SE, OTOH, just looks fine. But it has much lower resolution textures than current games.

Wolfenstein: The New Order is an OpenGL game, so it's clearly unrelated.
The Witcher 3 looks crisp because it uses an LOD Bias of -1 for pretty much all its textures. I don't think there's an issue with DXVK in that regard since it looks the same way on Windows for me.

Okay, I think we can close that. Thanks for the explanation.


External License reference is rejected by the validator

A license expression of the form DocumentRef-..:LicenseRef-.. is rejected by the validator but it should be accepted according to Annex D, both version 2.2 and 2.3.
The implementation does not consider the possibility of a external license reference. Subsequently the check for the correct declaration of the external document is missing.

Thank you very much for catching this, @LeBlue!
I opened a PR that should fix this issue, please have a look and review it if you like! :)


igv: 2.4.8 -> 2.4.9

Semi-automatic update generated by https://github.com/ryantm/nix-update tools. These checks were done:

built on NixOS
Warning: no binary found that responded to help or version flags. (This warning appears even if the package isn't expected to have binaries.)
found 2.4.9 with grep in /nix/store/q5c9jyg6gc4v3ns7rw5lxj7v4v916a7f-igv-2.4.9
found 2.4.9 in filename of file in /nix/store/q5c9jyg6gc4v3ns7rw5lxj7v4v916a7f-igv-2.4.9

cc @mimadrid for review

No attempt on aarch64-linux
The following builds were skipped because they don't evaluate on aarch64-linux: igv
No log is available.

Success on x86_64-darwin (full log)
Attempted: igv
Partial log (click to expand)
'igv.command' -> '/nix/store/adzbfdy6bgrj9ndm46avr61j1qybzyw0-igv-2.4.9/share/igv.command'
'igv.jar' -> '/nix/store/adzbfdy6bgrj9ndm46avr61j1qybzyw0-igv-2.4.9/share/igv.jar'
'igv.sh' -> '/nix/store/adzbfdy6bgrj9ndm46avr61j1qybzyw0-igv-2.4.9/share/igv.sh'
post-installation fixup
strip is /nix/store/4sdh09gmvl15cy0zb6i7mbvxh5syz206-cctools-binutils-darwin/bin/strip
stripping (with command strip and flags -S) in /nix/store/adzbfdy6bgrj9ndm46avr61j1qybzyw0-igv-2.4.9/bin
patching script interpreter paths in /nix/store/adzbfdy6bgrj9ndm46avr61j1qybzyw0-igv-2.4.9
/nix/store/adzbfdy6bgrj9ndm46avr61j1qybzyw0-igv-2.4.9/share/igv.sh: interpreter directive changed from "/bin/sh" to "/nix/store/pkjmwq7sqrvjg7cjiph6hq0khsmfl6p8-bash-4.4-p12/bin/sh"
/nix/store/adzbfdy6bgrj9ndm46avr61j1qybzyw0-igv-2.4.9/share/igv.command: interpreter directive changed from "/bin/sh" to "/nix/store/pkjmwq7sqrvjg7cjiph6hq0khsmfl6p8-bash-4.4-p12/bin/sh"
/nix/store/adzbfdy6bgrj9ndm46avr61j1qybzyw0-igv-2.4.9

Success on x86_64-linux (full log)
Attempted: igv
Partial log (click to expand)
'igv.sh' -> '/nix/store/q5c9jyg6gc4v3ns7rw5lxj7v4v916a7f-igv-2.4.9/share/igv.sh'
post-installation fixup
shrinking RPATHs of ELF executables and libraries in /nix/store/q5c9jyg6gc4v3ns7rw5lxj7v4v916a7f-igv-2.4.9
strip is /nix/store/b0zlxla7dmy1iwc3g459rjznx59797xy-binutils-2.28.1/bin/strip
stripping (with command strip and flags -S) in /nix/store/q5c9jyg6gc4v3ns7rw5lxj7v4v916a7f-igv-2.4.9/bin
patching script interpreter paths in /nix/store/q5c9jyg6gc4v3ns7rw5lxj7v4v916a7f-igv-2.4.9
/nix/store/q5c9jyg6gc4v3ns7rw5lxj7v4v916a7f-igv-2.4.9/share/igv.command: interpreter directive changed from "/bin/sh" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/sh"
/nix/store/q5c9jyg6gc4v3ns7rw5lxj7v4v916a7f-igv-2.4.9/share/igv.sh: interpreter directive changed from "/bin/sh" to "/nix/store/zqh3l3lyw32q1ayb15bnvg9f24j5v2p0-bash-4.4-p12/bin/sh"
checking for references to /tmp/nix-build-igv-2.4.9.drv-0 in /nix/store/q5c9jyg6gc4v3ns7rw5lxj7v4v916a7f-igv-2.4.9...
/nix/store/q5c9jyg6gc4v3ns7rw5lxj7v4v916a7f-igv-2.4.9

It looks good to me :+1:


Cannot use namespaced function in the apply function

{{ $a := apply $b "strings.Trim" "." " " }}

error calling apply: can't find function strings.Trim

But this works:
{{ $a := apply $b "trim" "." " " }}

@moorereason I know it's been a while, but you know this code pretty well. If you have a moment...


fix for TIKA-2783 contributed by JohnBergqvist

Hi,
I ran JaCoCo over the tika-core module, and found that the org.apache.tika.mime.HexCoDec class was missing unit test coverage.
I've written some tests for this class, with the help of Diffblue Cover. The majority of the class is now covered as a result of these tests.
Hopefully these tests should help you detect regressions caused by future code changes.

@kkrugler Many thanks.

@kkrugler Many thanks. The first test in the file has a length of 1, which causes the exception to be thrown.


Ui action fix

Still need to fix the bug... But have spend some time tidying the code.

@pazzarpj getting some eyes on this would be really good.
Two things I'm not sure about:

Should we be sending UI_block_start/end around user_action? I think yes but we didn't before either.
If we call user_yes_no or user_ok functions in the target of a user_action, they will clear the "Fail" button. I think in reality that is getting to the point where the whole intent of user_action is getting broken down, so might no be a big concern.

@pazzarpj pending any feedback you have, I believe this now fixes #50 and #54. Would appreciate a second set of eyes before merging.


Review Tokenization

Review tokenization and stripping punctuation.
Not sure why it says this in the git diff:
"ename": "NameError",
"evalue": "name 'string' is not defined",
I've imported string to use it for string.punctuation
The output on Jupyter looks correct to me. Attaching a screenshot here: https://discord.com/channels/1011761992819802183/1011761993268600923/1027395051371905045

Looks like the NameError gets removed when I pushed with output, but that makes the diff very large.


Refactor Flatten to first flatten the tree and then filter the results

Currently, the implementation of Flatten is a bit more complex than it needs to be. This is partly due to the way the loop mutates next in a couple of places and also doubly calls Unwrap and re-assigns err twice.
This could be simplified by first running the Unwrap loop to product a simple slice of errors. Then, once there's a slice, it would be easier to do the filtering with lookahead/lookbehind instead of (what is essentially) double step/next iterations etc.

I have a modified version of flatten in my repo (https://github.com/spearson78/fault/tree/floc) that doesn't have look ahead but is functionally equivalent. I was trying to make auto generated location optional so that a library can generate an error with a location that corresponds to the caller rather than a random line of code in the library. This reduces the amount of wrapping needed in user code.

This would be good to explore as a solution. I'm going to make some changes to the flatten call soon so it's at least easier to make simple changes/additions to.

Check out the latest release (v0.5.0) where I've rewritten Flatten to be more smart about duplicate nested error messages.
There's still some work to do around locations, it may be worth storing a full stack trace with each error step and unpacking the most logical frame when the error is flattened. Anyway, can move discussion for this to another issue.


DOCS-1881: Adding support for RKE2 in CC

Product Version(s):

Issue:

Link to docs preview:

SME review:

[ ] An SME has approved this change.

DOCS review:

[ ] A member of the docs team has approved this change.

Additional information:

Merge checklist:

[ ] Deploy preview inspected wherever changes were made
[ ] Build completed successfully
[ ] Test have passed

Closing for now, as this doesn't seem to be happening immediately.


Touch pointers draw incorrect rays on Mobile

Describe the bug
This is a carry over from https://github.com/microsoft/MixedRealityToolkit-Unity/issues/5390.
Using one or more fingers on a touch screen laptop. Purple rays are drawn by the pointer, yellow/green are the debug rays drawn by the pointer. Hence it appears that the pointer position is incorrect, but the rendering/line components are producing an error.
As an aside, using a ray for a touch pointer seems like a strange UX decision, as by default whenever the finger is down you would not be able to see the ray (since it should be casting from that point on screen using the camera frustrum).
To reproduce

Configure Microsoft Mixed Reality Toolkit v2.0.0 RC2.1
Configure/ensure input profile uses touchpointer.
Touch screen in editor and observe that touch-rays are drawn in the incorrect location.

Image / screen recording which makes the description clear:
https://i.stack.imgur.com/W9iEX.gif
Your Setup (please complete the following information)

Unity Version 2018.4.3f1
Microsoft Mixed Reality Toolkit v2.0.0 RC2.1

Target Platform (please complete the following information)

Android
iOS
Editor

As with #5390: Since we are seeing more and more customer projects on the horizon targeting mobile phones, and since the next push will likely include a focus on mobile, I'd like to propose an urgency of 'soon'. I'll go ahead and apply the tag but feel free to re-prioritize as necessary.


BUG: Cell.add_simulation_setup() missing

🔍 Before submitting the issue

[X] I have searched among the existing issues
[X] I am using a Python virtual environment

🐞 Description of the bug
Cell.add_simulation_setup() is missing despite delete_simulation_setup is here.
Also Cell.simulation_setup doesn't have setter otherwise we could pass a list of Simulation setups.
This is required when we clip a Cell, simulation setups are not duplicated so we need to explicitly copy the setup from parent to the clipped cell.
📝 Steps to reproduce
NA
💻 Which operating system are you using?
Windows
📀 Which ANSYS version are you using?
No response
🐍 Which Python version are you using?
3.10
📦 Installed packages
NA

@svandenb-dev The syntax for creating sim setups is different in pyedb-core. There is a create method on the simulation setup classes for creating them in a given cell. For example:
db = Database.create("test.aedb")
test_cell = Cell.create(db, CellType.CIRCUIT_CELL, "test_cell")
hfss_sim_setup = HfssSimulationSetup.create(test_cell, "test_sim_setup")

ok thanks it works


[FIX] Switch scores before luciphor

This was a regression after adding ConsensusID. Unfortunately, I still do not have a small Phospho data set for CI.

Have to merge for docker container update. After that, I will try to add some tests.


'RCTWebSocketProxy.h' file not found

there is a error when i run example.
react-native/React/Modules/RCTDevMenu.m:22:9: 'RCTWebSocketProxy.h' file not found

Should be fixed in f9e81d9bccc2960be28e4583120dba28deab6276

can confirm it was a bug and can confirm it is now fixed in master :)

The bug has been Fixed!
Thank you very much！

Just used npm to download 0.22.0-rc and went to rebuild my xcode project and I am getting this error which is failing my build.  I looked at the commit referenced by @satya164  above and my RCTDevMenu.m file contains the change introduced in that commit.

experiencing the very same as @JakeRuth for both, 0.22.0-rc and also the current master

Was the case for me too as of today with 0.22.0-rc

Any workaround ?

Made it work with latest npm / node without forgetting the react-native upgrade

Closing since this seems to be fixed by react-native upgrade.

@satya164 I am having this problem as well, and i'm on 0.22.2. I've confirmed I have the referenced commit as well. Any suggestions on where to go from here?
(reopening for now)

Note: I'm not using react-native upgrade because we aren't using the app template here :/

@lelandrichardson Does it happen in a brand new project?

No. Apologies, this was an issue with my understanding of cocoapods, not react native :(  closing again.

Also ran into this upon running npm install --save<EMAIL_ADDRESS>Builds work again after running a pod install:

I'm getting this with a brand new React Native app with react-native-firebase to build. Following the steps from:
react-native init MyApp

then in the ios directory I pod init with the pod file:
# Uncomment the next line to define a global platform for your project
platform :ios, '9.0'

target 'MyApp' do
  # Uncomment the next line if you're using Swift or would like to use dynamic frameworks
  # use_frameworks!

  # Required by RNFirebase
  pod 'Firebase/Core'
  pod 'RNFirebase', :path => '../node_modules/react-native-firebase'

  # [OPTIONAL PODS] - comment out pods for firebase products you won't be using.
  pod 'Firebase/Analytics'
  pod 'Firebase/Auth'
  pod 'Firebase/Database'
  pod 'Firebase/Messaging'

  pod "Yoga", :path => "../node_modules/react-native/ReactCommon/yoga"
  pod 'React', :path => '../node_modules/react-native', :subspecs => [
    'BatchedBridge', # Required For React Native 0.45.0+
    'Core',
    # Add any other subspecs you want to use in your project
  ]

  target 'MyAppTests' do
    inherit! :search_paths
    # Pods for testing
  end

end

target 'MyApp-tvOS' do
  # Uncomment the next line if you're using Swift or would like to use dynamic frameworks
  # use_frameworks!

  # Pods for MyApp-tvOS

  target 'MyApp-tvOSTests' do
    inherit! :search_paths
    # Pods for testing
  end

end

After running pod install, opening MyApp.xcworkspace, and building gives me the error:

/Users/nicholasstephan/code/MyApp/node_modules/react-native/React/Base/RCTTVRemoteHandler.m:25:9: 'RCTDevMenu.h' file not found

I'm using Xcode 8.3.3 and React Native 0.48.3.


Add an option to skip the commit collection

When a repository is shallow-cloned, a revision walk is not possible
further than the shallow depth. Add an option to the record build
command to skip the commit collection and let the user upload the commit
data in a separate workflow.

I think we still need to support "tagging" the build with a commit hash (for the purpose of computing CUT later), right?

I think we still need to support "tagging" the build with a commit hash (for the purpose of computing CUT later), right?

Yep. This doesn't stop that part (see the code after the commit collection). It gathers the submodules' and superproject's commit hashes.

I think we still need to support "tagging" the build with a commit hash (for the purpose of computing CUT later), right?

Yep. This doesn't stop that part (see the code after the commit collection). It gathers the submodules' and superproject's commit hashes.

Ah, of course! Thank you. I'll stay in my lane now 😄


Draft Editor doesn't always take focus when clicking between it and another control...

Sometimes it either takes a really long time to get focus after load, or won't let you click inside of it for a while. Later I noticed clicking between it and another control resulted in a similar behavior where it "randomly" won't accept focus. I did, however, notice that if you give focus to the control above it, that you can always tab to the draft editor to give it focus.

I think reading an issue in the draft-js-plugins repo, that I have narrowed this down. It's not that it doesn't take focus, it is that I was expecting it to receive focus if I click anywhere inside the text area, and it only takes click focus if you click in the left most portion of the text area inside the editor. It must not be the size of the entire (seemingly) editable area.

Narrowed it down a little further. It's not just the left side that will take focus, it's as if there is only a single line container that is text height, that will accept focus. If your min height is more than 1 line of text tall, any other location inside of the text area that you click will not give focus. I've seen live demos of like these on Heroku and I have checked them out and it doesn't behavior like this.

Turns out that only the draft root was getting focus.
The problem there is I had the focus code in the wrong place. I'll add a screen shot of my changes below. What fixed it is writing the focus method, and making sure it is referenced by the editor containing div's onClick event handler. Div's can't be focused, so be sure it's click, and link it to focus, which puts focus on the editor, the editor has to have the ref="editor" in order for this to work.


update the sample example of Readme.md

Description of changes:
Update the Sample component of Readme.md.
Related issues (if any):
Based to discussion opened in the issue #122 and some comments of some handlers I update the component mentioned in the Readme.md
Checks:

[x] Please confirm yarn run lint ran successfully
[ ] Please confirm that only /src and /examples/src are committed
[ ] [if new feature] Please confirm that documentation was added to the README.md

What's preventing this from being merged?
I like this library and it's been helpful to me. I have an issue that I would like to fix with a PR but I'm worried that if I submit one, it will be months to years until it is accepted.

@addisonElliott this hadn't been merged because we simply never got round to it.
I'll look into it now.


Implement uffd-wp support.

This commit implements the Linux 5.7 uffd-wp feature that enables
protecting a range of memory pages as "write protected" and receiving
events in user space about any writes to those pages.
The linux5_7 feature was added to enable the support.
A test was added to demonstrate how to use the feature.

The documentation regarding uffd-wp is, ahem, not great.  I tracked the commit that seemingly merged the feature into mainline kernel to a 5.7 tag, so I believe that's the minimum version required.

Weird, I'm running the same Ubuntu version in my VM and the kernel should be 5.8 and _UFFDIO_WRITEPROTECT should definitely be present in the bindgen output.

Erm wait, ubuntu-latest is 20.04 (5.4) and not 20.10, whoops!

I just looked into this and learned that, in Debian and Ubuntu, linux headers available under the standard system search path (i.e. those in /usr/include/linux) are determined by how glibc was compiled.
We can install the headers for a more recent kernel with apt install linux-headers-5.8.0-49-generic and then add /usr/src/linux-headers-5.8.0-49-generic/include/uapi/linux to bindgen's search path so they are picked up.

That would definitely help with at least testing the build, but it would be nice if GitHub actions offered non-LTS ubuntus to test with.


First measuredSignalTypes

from
https://github.com/openMetadataInitiative/openMINDS_controlledTerms/pull/434
https://github.com/openMetadataInitiative/openMINDS_controlledTerms/pull/435
https://github.com/openMetadataInitiative/openMINDS_controlledTerms/pull/436
@lzehl gave feedback on the PR, but it stopped there. I incorporated the feedback now.

updated and ready for a final review


Bump up to Hotfix Version

IMO, this may indeed be a practical fix, but shouldn't we bump versions as needed so we don't have to remember to change them back to 0 (and bump the minor or major) when merging/cherry-picking back into master? We had to do this manually during previews.

In general the flow will be make the change in master and then cherry pick it into the release branch in this case. However no matter which direction you merge there should be a merge conflict on the version property and you should generally always stick with the version that is in the branch and not override it. It should also be noted for this time we were asked to bump them all to help out the library team during this dec-rollup as we expect to have most of them ship in this time.

Perhaps an upfront check to make sure we don't collide with published packages before we try to publish (which, at least for nuget.org and npm I know, would fail) would be better?

We do have a check in our release pipeline that will fail if you try to publish version that already exists. We have considered pulling that closer to the PR validation but we don't want to do that until we have some better tooling for version updating.

Still, not all packages will release at the same time, so wouldn't leaving servicing branch service bumps in owners' hands be more reflective of their own releases?

Still, not all packages will release at the same time, so wouldn't leaving servicing branch service bumps in owners' hands be more reflective of their own releases?

That is fair we are mostly doing this at the request of the leads. @AlexGhiondea should we have individual owners bump their patch version as necessary?


Set in filter menu causes crash.

Not sure if the type makes a difference.
Filter type LP.
click the set button, causes crash.

This has been addressed


replay: improve segment downloading

[x] better error handling
[x] retry on failure
[ ] log download information. resolve https://github.com/commaai/openpilot/issues/22429:

average download speed: 594.98 KB/S
downloading segment [ 1 ] : 71.46 MiB 91% eta  2 s
downloading segment [ 0 ] : 71.53 MiB 97% eta  1 s

We don't want to spam with too much output. Can we only show the progress when it's blocking the replay?


[Mouse utilities] suggestion - add ability to use over Zoom

Description of the new feature / enhancement
Love the new "Find My Mouse"
Over Zoom, if you are sharing full screen, the people watching the Zoom share will see the effect of "Find My Mouse". But if you are sharing a single app window (rather than the full screen), they don't see the effect.
It would be great if the effect could also be seen with single app window shares.
Chris
Scenario when this would be used?
While doing a screen share over Zoom. It would let you highlight where the mouse cursor is for others viewing the Zoom session.
Supporting information
No response

I would say this is an #won't fix because is normal for Zoom and other video conference software to look the application you are sharing and the mouse utilities as two different applications.
IMO, the screen sharing will be the only solution.

Wow, thanks Franky920920. I always wondered why these sorts of pointer-enhancement tools didn't work when sharing a single app window over video-conference. What you say is like a big lightbulb going off - "Of course!!"
I am a huge fan of Cursor Highlighter and would love to see the customization capabilities in it to be incorporated into Find My Mouse. (https://sites.google.com/site/boisvertlab/computer-stuff/online-teaching#h.6uj1pu69f7rt)

I am a huge fan of Cursor Highlighter and would love to see the customization capabilities in it to be incorporated into Find My Mouse. (https://sites.google.com/site/boisvertlab/computer-stuff/online-teaching#h.6uj1pu69f7rt)

I'm linking you to #13808 for this suggestion :)

I just installed powertoy and tried find my mouse during a screen capture (shift-windows-s). Again, the function does not activate while the screen is blank for selection. In this situation often the mouse plays hide and seek :) I have 3 monitors and it would be very convenient to locate it. thanks, Andrea

as @franky920920 pointed out, I don't think we can really fix this as zoom / teams would lock to an application.  Even with our idea for presentation mode with showing mouse clicks, we don't think we can support the scenario of sharing a single app due to the fact they are actually different apps and the idea is to not over share data when you do a single app.


Redesign Footer to Include More Information about the Organization

Enter your suggestions in details:
Description
Currently, the footer only displays the logo, which doesn't offer much information about the organization. Let's redesign the footer to provide more details.
Footer Content Suggestion
Organization Logo
Continue displaying the organization's logo for brand recognition and visual appeal.
Data Repository Link
Direct link to the organization's data repository, where users can access datasets, resources, or related materials.
Flat Repository Explorer Link
Link to the flat repository explorer tool, allowing users to navigate and explore the organization's repositories efficiently.
Social Media Links
Links to the organization's social media profiles (e.g., Twitter, LinkedIn, GitHub) for users to stay updated and engaged.
Contact Information
Contact details such as email address or a contact form for users to reach out with inquiries .
Feedback Link
Github issue page link (Hardcoded) to get feedbacks (Link:- https://github.com/coronasafe/leaderboard/issues/new/choose)

I would like to work on this issue !!

@dgparmar14 please assign this issue to me

@rithviknishad please assign this issue to me

Hi @rithviknishad,
Could you please provide guidance on what the "Flat Repository Explorer Link" refers to?

Check-out https://flatgithub.com
You can keep it as an env. variable pointing to: https://flatgithub.com/coronasafe/leaderboard-data

Thanks, I’ll check it out.


Revert "Generalized the deduplication as a filter"

Reverts wikimedia/change-propagation#192
I would like to take this back. When I started to create a redid-based filter I've realized that this is a half-baked solution. WE can actually make this way more generic and apply to all the rules by default if we make some refactoring within the change-prop codebase.
cc @wikimedia/services

Coverage decreased (-0.2%) to 89.093% when pulling a2b4087b144676d7690866aed07d884371d2ecea on revert-192-new_dedupe into 51c5190d531aae125d187fbaaa2bb4e729293dad on master.

LGTM.


go-musicfox: 4.5.7 -> 4.6.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for go-musicfox is: Terminal netease cloud music client written in Go
meta.homepage for go-musicfox is: https://github.com/anhoder/go-musicfox
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact
Checks done

built on NixOS
The tests defined in passthru.tests, if any, passed
found 4.6.0 with grep in /nix/store/aja73xdc8264jbc0jh9ic4vw51xha1r3-go-musicfox-4.6.0
found 4.6.0 in filename of file in /nix/store/aja73xdc8264jbc0jh9ic4vw51xha1r3-go-musicfox-4.6.0

Rebuild report (if merged into master) (click to expand)

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

go-musicfox

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/aja73xdc8264jbc0jh9ic4vw51xha1r3-go-musicfox-4.6.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A go-musicfox https://github.com/r-ryantm/nixpkgs/archive/82637faae67b7149a5f767a23e9c33d47ffc4cb4.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/82637faae67b7149a5f767a23e9c33d47ffc4cb4#go-musicfox

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/aja73xdc8264jbc0jh9ic4vw51xha1r3-go-musicfox-4.6.0
ls -la /nix/store/aja73xdc8264jbc0jh9ic4vw51xha1r3-go-musicfox-4.6.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
nixpkgs-review result
Generated using nixpkgs-review.
Command: nixpkgs-review

x86_64-linux

:white_check_mark: 1 package built:

go-musicfox

Maintainer pings
cc @zendo @Ruixi-rebirth @Aleksanaa for testing.

[!TIP]
As a maintainer, if your package is located under pkgs/by-name/*, you can comment @NixOS/nixpkgs-merge-bot merge to automatically merge this update using the nixpkgs-merge-bot.

Add a :+1: reaction to pull requests you find important.

@NixOS/nixpkgs-merge-bot merge


[Feature request]: Automate management group scope deployment clean up

Description
Deployment quota often exceeding at management group scope.
Management group scope deployments fail when deployment count exceeds 800.
To overcome this, deployments that are no longer needed should be deleted from the history Ref Management group limits. This is currently being done manually.
The failure frequency increased after enabling telemetry settings, doubling up the number of deployments per pipeline run.
Error log example: https://github.com/Azure/ResourceModules/runs/6043758601?check_suite_focus=true#step:4:442

I guess we could debate whether that is a bug, or an enhancement. But it's in any case a pain ;)

To not run into API throttling limits, I suggest to not use the default PS-cmdlet (Remove-AzResourceGroupDeployment), nor the default REST-API call, but instead use the bulkDelete used by the AzurePortal (with maximum 100 items at a time):
Request URL: https://management.azure.com/batch?api-version=2020-06-01
Request Method: POST
Header Content Type: Content-Type: application/json
Payload:
{
    "requests": [
        {
            "content": {
                "EntityIds": [
                    "/providers/Microsoft.Management/managementGroups/<managementGroupId>/providers/Microsoft.Resources/deployments/pid-47ed15a6-730a-4827-bcb4-0fd963ffbd82-l6ql6gmfsjros",
                    "/providers/Microsoft.Management/managementGroups/<managementGroupId>/providers/Microsoft.Resources/deployments/roleAssignments-20220419T1104096929Z",
                    "/providers/Microsoft.Management/managementGroups/<managementGroupId>/providers/Microsoft.Resources/deployments/roleDefinitions-20220419T1104041183Z",
                    "/providers/Microsoft.Management/managementGroups/<managementGroupId>/providers/Microsoft.Resources/deployments/pid-47ed15a6-730a-4827-bcb4-0fd963ffbd82-wpnvthqx5ddns",
                    "/providers/Microsoft.Management/managementGroups/<managementGroupId>/providers/Microsoft.Resources/deployments/wpnvthqx5ddns-RoleDefinition-MG-Module",
                    "/providers/Microsoft.Management/managementGroups/<managementGroupId>/providers/Microsoft.Resources/deployments/pid-47ed15a6-730a-4827-bcb4-0fd963ffbd82-iaxflwtdbhwgk"
                ],
                "Type": "Default"
            },
            "httpMethod": "POST",
            "name": "99b3bff9-bcd6-4ebc-9546-be0051a13018",
            "requestHeaderDetails": {
                "commandName": "HubsExtension.armbulkdelete"
            },
            "url": "/bulkdelete?api-version=2014-04-01-preview"
        }
    ]
}

I am thinking we can tackle this in a way that doesn't get embedded into our deployment / validation scripts. But a 'maintenance' type pipeline that runs either at specific intervals or whenever certain PRs are completed. This way it's decoupled and is portable to be used elsewhere. Thoughts?

Is this duplicate of https://github.com/Azure/ResourceModules/issues/1342 ?

@MariusStorhaug reading the other issue, it is something else

Hey @ahmadabdalla , I just created a PR for a utility that I created for this still manual Deployment-Removal. Whatever we do (e.g. have a re-curring pipeline running), we can use this script to clean up. For the time being I think it is just useful to have around.

Reopening since the issue is about automating the deletion through pipelines

I was thinking about this a bit. I think we can do this in one of 2 ways:

Either we invoke the cleanup before/after each pipeline run (i.e. somewhere in the validate deployment template/action) OR
We add a platform pipeline that runs e.g. every week.

Personally I'd vouch for option 2, with some logic like

Only remove successful deployments
Unless the deployment happened more than 4? weeks prior to the pipeline run.

This should be pretty easy to implement as we have the function available and would only need to filter the deployments out accordingly.

Agree with the proposal.
Adding a couple of further points (the second most probably being a separated issue):

The platform pipeline should be implemented for both ADO and GH. On our side we should avoid to have them scheduled at the same time.

I'd anyway suggest to have option and clear guidelines to opt out from management group level operations, since many wouldn't agree to have service principal permissions higher than subscription scope. Users falling into this category should remove e.g. the management group module and related validation pipeline, clean up authorization modules happening at multiple scopes (e.g. rbac, policies). Of course for those users the problem related to this issue wouldn't occur. But they shouldn't register the cleanup platform pipeline.


Add Ok and Abort structs

Also add:
    struct Ok end
    struct Abort end
    struct TrapPass end
    struct TrapFail end

Done


Fix error search in SQLite

SQLite does not support the ILIKE operator. We need to use the LIKE operator instead, which performs a case-insensitive match for ASCII characters.
Since we are looking at stacktrace lines and module names I think that it is fair to expect ASCII characters 99%+ of the time anyway.
This pull request fixes the problem by detecting the current database adapter and using LIKE or ILIKE accordingly. I've also extracted the search function out of the dashboard and unit-tested it to ensure that it works and doesn't break by mistake.
Closes #50

This should be ready to review again @odarriba


Fix broken link in docs

Thanks for the fix! Please refer to our contribution guide on how to write git commit messages.

LGTM, thanks! +1
One more thing is needed, please update docs/release-notes/release-notes-0.14.0.md (add this PR to the appropriate section) so that GitHub CI doesn't complain.

Done!

Replaced by https://github.com/lightningnetwork/lnd/pull/6080 to speed up review process. Original commit author was preserved, thank you for your contribution.


Update recommendations.yaml for virtualMachineScaleSets

Update recommendations.yaml for virtualMachineScaleSets to not have virtualMachines recommendations

Overview/Summary
The virtualMachineScaleSets/recommendations.yaml had one recommendation for Microsoft.Compute/virtualMachines, which doesn't belong here.
Related Issues/Work Items
Replace this with a list of related GitHub Issues and/or ADO Work Items (Internal Only)

To associate a GitHub Issue, use a key word preceded with the GitHub issue number.
To associate an ADO Work Item, use the key word AB# succeeded with the ADO Work Item ID.

This PR fixes/adds/changes/removes
Closes #156 156
As part of this pull request I have

[X] Read the Contribution Guide and ensured this PR is compliant with the guide
[X] Checked for duplicate Pull Requests
[X] Associated it with relevant GitHub Issues or ADO Work Items (Internal Only)
[X] Ensured my code/branch is up-to-date with the latest changes in the main branch
[X] Ensured PR tests are passing
[X] Performed testing and provided evidence (e.g. screenshot of output) for any changes associated to ARG queries
[X] Updated relevant and associated documentation (e.g. Contribution Guide, Docs etc.)

Retracting this one


Add program version to snapshot

What does this PR change? What problem does it solve?
Include the program version in the snapshot metadata.

Was the change previously discussed in an issue or on the forum?
Fixes #4188

Checklist

[x] I have read the contribution guidelines.
[x] I have enabled maintainer edits.
[x] I have added tests for all code changes.
[x] I have added documentation for relevant changes (in the manual).
[x] There's a new file in changelog/unreleased/ that describes the changes for our users (see template).
[x] I have run gofmt on the code in all commits.
[x] All commit messages are formatted in the same style as the other commits in the repo.
[x] I'm done! This pull request is ready for review.

LGTM.

LGTM.


Improve UX for the Game Setup window

Benefit description
The setup window in 2.0, althought functional, il cluttered and hard to eye-scan.
Some of the problems we thing we should address:

The setting of the game should be done pre-selecting a "game type", like "Pixel Art", "High Res", and others if we think it's worth adding more.
Parameters are pre-set and can be customized only by opening a section in the setup window (like "Advanced options" or "Customize")
The GUI selection section would scale badly with the addition of more elements. We need to make it sleeker and provide more visual and less textual info.

This issue is mildly related to #251. Addressing this will hopefully solve that, too.
Solution description
ATTOW there is no clear solution, just a bunch of ideas that need to be discussed and rendered into a design.
We'll provide a reference design as soon as we have it.
Exclusions
These changes may highlight the need for resolution-specific game GUIs. They are out of the scope of this issue.
Implications
We may want to change the default parameters for pixel art games from a very retro 320x180 to a retro-inspired 356x200 or slightly larger 384x216 (both 16:9, the second one is very good for large GUIs like the 9verbs, leaving more real estate for the game environment).
 We may also want to provide interfaces in different resolutions, but that will be out of scope (see "Exclusions").

Looking forward to start creating the HD version of each template!!!


World and Dimension configs inheriting 0 values for economy, causing global to be overridden by default

As per title, world and dimension configs are created with defaults based on global config, which with defaults are...
    economy {
        # Cost to purchase a claim block. set to zero to disable purchase.
        claim-block-cost=0.0
        # Return on a sold claim block. set to zero to disable sale.
        claim-block-sell=0.0
    }

    town {
        # The required amount of funds to create a town. (Default: 0)
        # Note: This requires an Economy plugin.
        creation-cost=0.0
    }

They should be...
    economy {
        # Cost to purchase a claim block. set to zero to disable purchase.
        claim-block-cost=null
        # Return on a sold claim block. set to zero to disable sale.
        claim-block-sell=null
    }

    town {
        # The required amount of funds to create a town. (Default: 0)
        # Note: This requires an Economy plugin.
        creation-cost=null
    }

With defaults of 0 present, changes to global do not work.

Workaround during bug not fixed: Either set costs in every world config or remove world configs and restart the server.

Closing as this appears to have been a migration related issue and does not occur on new setups.


Gemfile test

@corlassion Also, make sure to run bundle install locally which will generate a Gemfile.lock file.


Use System.Reflection.Metadata to harvest type info without assembly loading

Sample code if you want to try Reflection.Metadata:
var assemblyPath = @"d:\github\azure\azure-sdk-for-net3\artifacts\bin\Azure.Core\Debug\net461\Azure.Core.dll";
using (Stream stream = File.OpenRead(assemblyPath))
using (PEReader reader = new PEReader(stream))
{
	var mr = reader.GetMetadataReader();
	foreach (var tdh in mr.TypeDefinitions)
	{
		var td = mr.GetTypeDefinition(tdh);
		if ((td.Attributes & TypeAttributes.VisibilityMask) == TypeAttributes.Public)
		{
			Console.WriteLine(mr.GetString(td.Name));
		}
	}
}

Originally posted by @pakrym in https://github.com/Azure/azure-sdk-for-net/pull/8098#issuecomment-542740483

Closing this one. I can't even find the script for which this was intended. If it ever comes up again, we can use this other assembly to avoid all the assembly resolution I had to do in-proc using System.Reflection.

Closing this one. I can't even find the script for which this was intended. If it ever comes up again, we can use this other assembly to avoid all the assembly resolution I had to do in-proc using System.Reflection.


Update core.py to use pathlib

⚠ Make sure you're contributing to the 0.4.0 branch!

core.py's import_module and run functions currently use the os module for working with paths.
I believe these two can be refreshed with some pathlib.

Hi,
What is the "dahlia" dependency listed here? Poetry on my system cannot find it.

Hi,
What is the "dahlia" dependency listed here? Poetry on my system cannot find it.

Hey, I've also had some issues with it with version resolving in poetry—not sure what's the issue, maybe I set it up incorrectly? Anyway, here's the repo and the PyPI page.


vue.common.js:967 [Vue warn]: Invalid prop: type check failed for show="{{@showModal}}". Expected Boolean, got String.

I copied the example from http://yuche.github.io/vue-strap/ for the modal, and I'm getting multiple Vue warnings, and when clicking the button the modal doesn't appear.
Vue warnings:
[Vue warn]: Invalid prop: type check failed for show="{{@showModal}}". Expected Boolean, got String.
[Vue warn]: Invalid prop: type check failed for width="400". Expected Number, got String.
[Vue warn]: Invalid expression. Generated function body:  scope.click:scope.showModal=true

I'm just trying to use the default example for a modal, what's wrong here?

Found this fiddle https://jsfiddle.net/fqdx8auL/ on another issue, solved my problem.

This has been updated in the docs, it might be the case that @yuche hasn't updated or merged the githup pages site yet. Since I am not really familiar with gh-pages, I'll let him chime in and possibly update the docs.

@amanpatel just noticed that in the /doc dir.  Definitely should be updated in both spots, seeing as many people likely use the demos.
Thanks for your work guys.

@matisoffn Never used gh-pages before. I am sure yuche will have to grant me permission to his site. I've assinged this task to him.

@matisoffn  Just updated the gh-pages branch (took a bit of work for some reason it had conflicts since it was out of date for a while). In either case, the docs are updated!


[8.x] Customize type column in database notifications using databaseType me…

By this pull request, we can customize the type column in the database notifications.
By default, Laravel use class_name($notification) for the type column, and this can be undesirable on the client-side.
class InvoiceNotification extends Notification implements ShouldQueue {

    public function via($notifiable)
    {
        return ['database'];
    }

    public function databaseType()
    {
        return 'DAILY';
    }

Are you completely sure this actually works?  I've been trying to do this myself a couple of times but there was always a snag I ran into. Can't exactly remember which ones though 🤔

Yes, I test it, and works for me.

Thanks for your pull request to Laravel!
Unfortunately, I'm going to delay merging this code for now. To preserve our ability to adequately maintain the framework, we need to be very careful regarding the amount of code we include.
If possible, please consider releasing your code as a package so that the community can still take advantage of your contributions!
If you feel absolutely certain that this code corrects a bug in the framework, please "@" mention me in a follow-up comment with further explanation so that GitHub will send me a notification of your response.

@taylorotwell Thanks for your reply, This PR is similar to Relation::enforceMorphMap and your reply does not convince me!
Notification record in DB is like below:
{
"notifications": [
{
"id" : "",
"type" : "App\Notifications\LikeNotification",
"notifiable_type" : "",
"notifiable_id" :,
"data" : "{}",
"read_at" : ,
"created_at" : "",
"updated_at" : ""
},
]}


What parameter to define for the opcode::close optional file_index?

@quininer @lucab I would like to add the ability to close a fixed file table entry. If I follow the model created by #179, the API will allow a value representing auto. I can go with that for now. It will compile and work and if the user uses the auto function to create the entry by accident, they'll get a runtime error that the index was out of range. Is that okay? I can provide a warning in the function's comment section to that effect.

It is my understanding that IORING_OP_CLOSE only takes FDs/fixed-files as inputs, so I think that following #179 for this one is not a good idea (the approach there is is ok fixed-file outputs).
I think prior art in this library points towards using the UseFixed sealed trait :
https://github.com/tokio-rs/io-uring/blob/dcf6a124926cfb32bc94ff0b617bba6844bf54b6/src/types.rs#L17-L19
That would allow internally matching on the two variants:
https://github.com/tokio-rs/io-uring/blob/dcf6a124926cfb32bc94ff0b617bba6844bf54b6/src/types.rs#L7-L11
Overall the close operation looks a bit similar to fsync, which is currently implemented this way:
https://github.com/tokio-rs/io-uring/blob/dcf6a124926cfb32bc94ff0b617bba6844bf54b6/src/opcode.rs#L221-L229

@lucab I agree with you. I'm happy to change what I wrote in #181 yesterday to follow this line of reasoning if @quininer agrees this would be better.
The internal logic to opcode::Close would be different than how other functions have use the sealed fixed parameter but that's an easy technicality.

Done. It's better with the UseFixed trait.


Update README.md

@orenzohar I'll take a look. I think this needs to go to a separate section about the build process.

 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.

This is outdated. A lot has been added. See latest readme and if needed open a new PR.


Use patient everything in bulk export

This provides enough code functionality to satisfy "ONC Certification (g)(10) Standardized API", part "8 Multi-Patient Authorization and API STU2".  The remaining failures are malformed FHIR resources, nothing todo with the Bulk Data API itself.

Coverage decreased (-0.007%) to 94.096% when pulling efe4a1dbd5f7a1c874d049b10ade7ba7864b7328 on cody-bulk-export-patient-everything into de2b1df9cb1f8d29138de6e850d5d24f25701b23 on main.


Custom 404

Looks like Divshot is serving up a standard 404.  For now, lets use the existing 404: dashboard.aptible.com/asdf https://dashboard.aptible.com/404

@sandersonet Do you mean a catchall route for ember to display when it doesn't recognize the route? Right now divshot is configured to serve the index.html for any route it doesn't recognize.

closed by #218


[wip] updating infra conversion job polling timers

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1688992

Could/should these be in Settings?

Could/should these be in Settings?

Good question @djberg96
What do you think @fdupont-redhat ?

@miq-bot add_labels transformation, enhancement

@miq-bot add_labels hammer/yes

👍

@jameswnl Moving it to Settings could be another PR as this one will just revert the values to previous ones.

@simaishi corrected the related BZ to https://bugzilla.redhat.com/show_bug.cgi?id=1692952

Hammer backport details:
$ git log -1
commit 6b6a8db4657096b7e9e4029edbc33694dbff42bf
Author: Adam Grare<EMAIL_ADDRESS>Date:   Fri Mar 29 09:03:59 2019 -0400

    Merge pull request #18597 from jameswnl/numbers

    updating infra conversion job polling timers

    (cherry picked from commit 65cd621d09f08a62cf05c83b3f7488918fdf2d35)

    Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1696456


"ci-status" enhancements?

I just discovered the ci-status command, which is neat.
It lets you enter a SHA or a branch name. But the hub bash completion  script does not seem to provide auto-completion for hub ci-status on branch names, it would be convenient if it did.
Additionally, what one really often wants to know if the ci-status of a certain pull request. What you're going to see for CI if you go look at that PR in the Github Web UI. While that is some branch, you might know the PR number rather than the branch name. Is it feasible to enhance ci-status to take a PR# too?

But the hub bash completion script does not seem to provide auto-completion for hub ci-status on branch names, it would be convenient if it did.

It might be! Pull requests welcome.

Is it feasible to enhance ci-status to take a PR# too?

That's an interesting idea! I never considered it, but it can make sense. I wanted to add PR checks status information to hub pr list, but right now that has to wait until some GitHub API inconsistencies are solved our end for the results to be accurate.

In the meantime, here is how I query PR Statuses + Checks using `hub api` and `jq`:
pr-checks() {
  local head_sha
  head_sha="$(hub api graphql -F number="${1?}" -f query='
    query($number: Int!) {
      repository(owner: "{owner}", name: "{repo}") {
        pullRequest(number: $number) {
          headRefOid
        }
      }
    }
  ' | jq -r '.data.repository.pullRequest.headRefOid')"
  hub api -H 'accept: application/vnd.github.antiope-preview+json' graphql -f "sha=$head_sha" -f query='
    query($sha: GitObjectID) {
      repository(owner: "{owner}", name: "{repo}") {
        object(oid: $sha) {
          ... on Commit {
            status {
              state
              contexts {
                context
                state
                targetUrl
              }
            }
            checkSuites(first: 100) {
              edges {
                node {
                  conclusion
                  checkRuns(first: 100) {
                    edges {
                      node {
                        name
                        conclusion
                        detailsUrl
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  ' | jq -r '
    .data.repository.object |
      (.status.contexts[] | [.context,.state,.targetUrl] | @tsv),
      (.checkSuites.edges[].node.checkRuns.edges[].node | [.name,.conclusion,.detailsUrl] | @tsv)
  ' | sort -u
}

# usage for PR #123
pr-checks 123

What about also showing the FAIL/PASS sign in the hub pr list too? Would be an awesome addition for a quick overview of the pending PRs, and which are "safe" to merge.


The file of 80mn_cifar_idxs.txt

Hi, thanks for your insightful work.
Could you provide the file of "80mn_cifar_idxs.txt " used for filtering out CIFAR images in Tiny-Imagenet.
Thanks a lot.

I found it at here


Add a trait func which should check the presence of CamelCatalog before execution

With #5378 we've added a check into all those traits that require the presence of a CamelCatalog in order to be executed. It would be nice to refactor that work and to transform that check into a generic trait func which can also be used by the documentation process and be able to automatically generate documentation. In this way we can let the user know which are the traits that cannot be executed when running a "sourceless" or a synthetic Integration.

Closed by #5798


Implement IntoView for Rc

Indeed as suggested on Discord, Option<str> is a much better choice than Option<String>, and already supported.

Thanks for noticing this and your work to implement it! This implementation can be improved. Adding it to the viewable_primitives list will call .to_string() on the Rc<str>, allocating a new String with the same contents, and then converting that into an Oco<'static, str>. Oco<_> is a type we use internally that works like Cow<_>, but also has a reference-counted branch (so it can hold a &'static str, Rc<str>, or String)
You can convert an Rc<str> directly into an Oco<'_, str> without the additional .to_string() allocation and copy. So adding something like this, in the same file, right below the impl IntoView for Cow<'static, str> would be ideal!
impl IntoView for Rc<str> {
    #[cfg_attr(
        any(debug_assertions, feature = "ssr"),
        instrument(level = "trace", name = "#text", skip_all)
    )]
    #[inline(always)]
    fn into_view(self) -> View {
        View::Text(Text::new(self.into()))
    }
}

(note this is identical code to the Cow<_> implementation -- since both implement Into<Oco<_>> they are the same)

Thanks so much! :tada:


Provide a path to python-requirements.txt w/ installing Python deps

This PR is a fix to #100.
When installing Python modules, this PR adds a verification to the process:

If ${KIRI_HOME} is set and if ${KIRI_HOME}/python-requirements.txt exists, we install Python modules from the local python-requirements.txt file.
Else, we install the modules that are listed in the raw python-requirements.txt file on the GitHub repo

Before merging, I would check with @MarcelRobitaille, as this fix may hinder on the build process for the AUR package he maintains, as per #82.

Thanks for your PR. I changed it a bit.
If KIRI_HOME is empty then it sets it with "./" as it was run locally for the first time.


[SC] Introduce State object

Introduces a 'State' object, which represents the state of the world during an entire contract operation.
The initial state is set up in the executor after receipt of contract data from the outside. External messages invoke create/calls on a contract, which themselves generate internal messages. State handles each of these scenarios, invoking the VM, metering gas, and updating logs and balances as appropriate.

Going to take a while for me to understand, but so far:

Why do we startTracking() in the internalexecutor only?

Imagine we make a call from SmartContractsController (e.g. ContractBalance) while a block is going through the CoinViewRule. We could get results that shouldn't be there if we query at the wrong time, because we're using the top-level staterepositoryroot. That top-level root should remain untouched - maybe it needs its own interface to only query information, and get a MutableRepository like the ones we already have, which we can happily pass wherever we want.

StateSnapshot, State, ContractState, ContractStateRoot, AccountState. We have to do something here, it's quite difficult to follow

The vars in State.cs make it hard to follow - could you apply the 1-click VS fix? Thanks

Woops, it's ready to go in, just the ExecutorSpecification test needs fixing


Cursor colours in source mode are very hard to see

The cursor colour in the dark modes is almost invisible because it's black or dark grey. And in the light modes it's also very hard to see because it's white.
This is in source mode.

Are you on Windows? For me the cursor looks fine (see the pictures)

If that's the case I will look into it, I will be testing the theme on Windows soon. Thank you!

I am on Windows.

Hey! I just pushed a new release (v1.1.1) including a fix for source mode. The cursor now follows the text color, so it's actually visible. There is still a problem within code blocks, I'm currently trying to fix that one, but source mode should work.
Thank you for reporting this issue and using the theme 😄!


Error: Resource not accessible by integration on PRs raised by dependabot

When a PR is raised by Dependabot (or anyone without write access to a repo), although all the tests pass, the action is unable to annotate the PR, instead throwing an error e.g. and the workflow fails:
0s
Run<EMAIL_ADDRESS>  with:
    access-token: ***
    junit-file: junit.xml
    run-name: build
    check-name: Jest
    working-directory: .
Error: Something went wrong: Error: Request to create annotations failed - request: {"owner":"mnbf9rca","repo":"IsTheTubeRunning","head_sha":"8e7ba3d9835e3a4070fba[1](https://github.com/mnbf9rca/IsTheTubeRunning/actions/runs/3926652650/jobs/6716566541#step:6:1)994b40b5[2](https://github.com/mnbf9rca/IsTheTubeRunning/actions/runs/3926652650/jobs/6716566541#step:6:2)14[3](https://github.com/mnbf9rca/IsTheTubeRunning/actions/runs/3926652650/jobs/6716566541#step:6:3)69da6c","name":"Jest","conclusion":"success","output":{"title":"Jest Test Results","summary":"#### These are all the test results I was able to find from your jest-junit reporter\n**60** tests were completed in **[5](https://github.com/mnbf9rca/IsTheTubeRunning/actions/runs/3926652650/jobs/6716566541#step:6:5).557s** with **[6](https://github.com/mnbf9rca/IsTheTubeRunning/actions/runs/3926652650/jobs/6716566541#step:6:6)0** passed ✔ and **0** failed ✖ tests.","annotations":[]}} - error: Resource not accessible by integration

I believe this will happen whenever someone raises a PR against a repo that they don't have write access to.
Another action which i use for Python coverage reporting (python-coverage-comment) solves this by publishing the coverage report as an artefact when the tests are executed, and then fetching it in a separate workflow to report. Is that possible with this action?
here's the broken JS workflow:
name: Tests CI

on: [push, pull_request]

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: check out source code
        uses: actions/checkout@v3
      - name: set up Node.js
        uses: actions/setup-node@v3
        with:
          node-version: '18'
      - run: npm install
        name: run npm install
        env:
          DOTENV_KEY: ${{ secrets.DOTENV_KEY }}
      - run: npm run test:ci
        name: execute tests
        env:
          DOTENV_KEY: ${{ secrets.DOTENV_KEY }}
      - name: report junit results
        uses<EMAIL_ADDRESS>        if: always() # Or use "continue-on-error: true" in previous test step
        with:
         access-token: ${{ secrets.GITHUB_TOKEN }}

Hey @mnbf9rca! Unfortunately this is actually a security feature of dependabot's integration in GitHub. PRs that are triggered by dependabot (either push or pull_request) are assumed to run in a non-secure environment and therefore do not have access to secrets. So jest-report-action actually receives and empty string in access-token: ${{ secrets.GITHUB_TOKEN }} and therefore the request to create the PR annotations fails.
Here's the link to the official information regarding this change: https://github.com/dependabot/dependabot-core/issues/3253#issuecomment-797125425
As to a solution, yes what python-coverage-comment is using is the correct workaround for this issue. Since jest-report-action only expects the report file you can use another action to upload the junit.xml to an artifact and then have the next workflow pick it up/downloading it and running jest-report-action with that junit.xml file as input.
You can use https://docs.github.com/en/actions/using-workflows/storing-workflow-data-as-artifacts#sharing-data-between-workflow-runs as inspiration for how to make the artifact upload/download work.
Take a look at the dependabot link for tips on how to trigger the second workflow run so that it has access to the secrets.


Add support for test phases

As discussed on the stakeholder meeting, there are use cases related to tracking individual results of test "phases". These can be created using one of the following ways:

defining a beakerlib phase using rlPhaseStart and rlPhaseEnd
explicitly calling rstrnt-report-result to submit a subresult

When run in Beaker, the rlPhaseEnd command called during a beakerlib test execution actually calls rlReport which uses BEAKERLIB_COMMAND_REPORT_RESULT command to report the result and, if I'm not mistaken, this defaults to using rstrnt-report-result. @sopos, please correct me if I'm wrong.
The effect is that each beakerlib phase and rstrnt-report-result call create a "subresult" which is shown in the Beaker web interface under the actual test. The proposal is to add a similar support for subresults to tmt.
Here are some more ideas caught from the brainstorm:

We could inject a custom script using BEAKERLIB_COMMAND_REPORT_RESULT and perform necessary actions on the guest
The result specification could be extended to include a list of subresults (which would be similar to the check attribute)
It would be good to report detected avc failures for each test phase separately
Report plugins would have to invent the proper mapping to e.g. junit format as the spec does not know subresults

All in all it seems this would bring a substantial level of complexity (currently the test granularity was simply defined by the test metadata definition for each test) so we should discuss this well before jumping into the implementation.

@psss I quickly checked a junit format and it seems like there is infrastructure to support subtests/phases
classname - could be used for a parent test name
name - could be used for a subtest/phase
https://github.com/testmoapp/junitxml

According to
https://www.ibm.com/docs/en/developer-for-zos/14.2?topic=formats-junit-xml-format
<testsuite> has child elements <testcase>, not <testsuite> again. We should be clear in which artifacts these phases should appear and how those artifacts are going to be used. Do we know if the proposed XML with nested <testsuite> elements would be compatible with ReportPortal for example?

FYI, I just tried to import https://github.com/testmoapp/junitxml/blob/main/examples/junit-basic.xml to RP and it went well, creating nested structures for testsuites. So at least from the RP perspective we may be fine.

Note: Beakerlib executes BEAKERLIB_COMMAND_REPORT_RESULT only if TESTID is set (https://github.com/beakerlib/beakerlib/blob/4321c54e2e99f74b91c9376aa4324dafd0300c3d/src/testing.sh#L1075) - we don't set it in tmt yet.

Just FYI, I was experimenting with a nested structure of <testsuite> using a junit-xml but the library does not support it. There are unmerged patches that add the support for nested <testsuite> structures (quickly tested - they seem to work fine), but the library is outdated and unsupported (the last commit was 4 years ago).
I have been searching for suitable alternative libraries, but so far, I haven't found any. Any ideas?

Doing a fallback to own implementation should not be that hard, note that there is a nice way via attr/cattrs we use in Testing Farm and @janhavlin was working on it and could help porting it to tmt:
https://gitlab.com/testing-farm/gluetool-modules/-/tree/main/gluetool_modules_framework/libs/results?ref_type=heads

Note breakers is able to produce the journal.xml in the breaker format as well as in the xunit. However, I was recently contacted by someone who was having an issue where the respective xml python module was missing which causes just an error and the xml file not being created.
It might be good if tmt was able to parse the journal.meta, i.e. to use the beakerlib's code to transform it (using the journalling.py).


Bug in ADaM ADSL example

The following result from the ADaM ADSL webpage doesn't look as expected.

By the way, there is a typo in the TOC:

There are two typos in the following comment:

thanks Stefan - i'll take a look this week


use python-webpack-boilerplate

Use python-webpack-boilerplate to import flowbite to Django

Hey @michael-yin,
Thanks for your contribution.
Can you please explain what the change is about, how will it affect the current setup and how is it better than the previous one?
I see that it's pretty nice that you've included Webpack into the configuration (which we also use), I just want to make sure that this is a change that will be stable and makes sense.
Thanks a lot!

@zoltanszogyenyi
python-webpack-boilerplate is inspired by rails Webpacker, it help developers to create frontend project which is bundled by Webpack, and also has code linting, so developers can get it working without touching tedious config.
The project also has npm run start command, which can let developers use auto reload feature. If user edit Django templates, the web page on the browser will auto refresh, which is convenient.
What is more, it can also be used with Flask, which means Flask users can also use Tailwind CSS and flowbite in convenient way.
I agree we can treat this as secondary or advanced solution.

Hi, @zoltanszogyenyi
After think, I think we can publish the doc in this way

The doc have URL https://flowbite.com/docs/getting-started/advanced-django/
It will not exist in the left sidebar.
In the header and footer of https://flowbite.com/docs/getting-started/django/ , we add some words and a link to the advanced-django tutorial

If you want a complete solution with Tailwind CSS and modern Javascript, please take a look at the Advanced Tailwind CSS Django - Flowbite

Is that ok for you?
Thx.


Pixelated images are generated instead of faces

Hi Yu,,
I'm glad to have stumbled on your GAN project. I followed the directions, installed the appropriate libraries and am able to run 'python generate_images.py' or 'python generate_images.py --factor 1' etc without any errors.
But it always generates pixelated images that don't resemble faces. Any ideas what's going on?
I'm a cognitive neuroscientist (MD, PhD) that thinks this could be a very useful tech for face recognition tasks/tests or emotional tests/tasks.
Best,
Omar

My bad. My computer was Windows.  Set it up on a Linux instance -- works great. Thanks.


Testing: npm link .. fails for me

npm link ..
npm ERR! Darwin 15.6.0
npm ERR! argv "/Users/gregor/.nvm/versions/node/v6.4.0/bin/node" "/Users/gregor/.nvm/versions/node/v6.4.0/bin/npm" "link" ".."
npm ERR! node v6.4.0
npm ERR! npm  v3.10.3

npm ERR! May not delete: /Users/gregor/Projects/pouchdb-adapter-fs/pouchdb
npm ERR!
npm ERR! If you need help, you may report this error at:
npm ERR!     <https://github.com/npm/npm/issues>

npm ERR! Please include the following file with any support request:
npm ERR!     /Users/gregor/Projects/pouchdb-adapter-fs/pouchdb/npm-debug.log

I suggest we add a section Testing to the README and ask people to git clone pouchdb into a different repository, install dependencies and then run npm link /path/to/pouchdb-adapter-fs and then run CLIENT_ADAPTER=pouchdb-adapter-fs npm test in the pouchdb folder?
That would be a simple first step. In general it would be nice to have a best practice for PouchDB adapter developers to test their adapter using the pouchdb test suite

Also is CLIENT_ADAPTER the right environment variable? I can’t find it anywhere in PouchDB’s source. Is it ADAPTER? But when I run npm test in the pouchdb repository it still runs the whole suite against CouchDB et all while I just want to test pouchdb-adapter-fs

Yeah I added CLIENT_ADAPTER in a branch and then forgot to open up a PR. There was no easy way I could find to test this thing. Tempted to just copy-paste PouchDB's test suite into this repo and then tweak it until it works. :/

Also yeah, the test suite requires CouchDB because it needs to test replication. Alternative is to test both fs as a client and as a server, but that requires pouchdb-server.


Update to CBMC version 6.1.0

Updates to match changes to the GOTO binary format.
Resolves: #2952, #2972, #3287
This includes changes our handling of storage markers to be marking is-alive only rather than treating StorageLive as creating a new object. That is, object instances are now tied to their Mir-provided declarations (which, at present, only appear once per function). To still account for when Rust scopes deem an object to be alive, we use StorageLive and StorageDead to update __CPROVER_dead_object. This (global) variable is used by CBMC's pointer checks to track when a pointer may not be safe to dereference for it could be pointing to an object that no longer is in scope.
Resolves: #3099
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 and MIT licenses.

Needs https://github.com/diffblue/cbmc/pull/8363 to be merged (and a new release containing that PR to be produced) to address remaining performance issues.

Needs diffblue/cbmc#8363 to be merged (and a new release containing that PR to be produced) to address remaining performance issues.

Done, now waiting for CBMC 6.1.0 to be available via brew.

How does the change in CBMC's default verbosity affect the Kani output? Is the change worth pointing out in the CHANGELOG.md?

I think we used to see loop-unwinding information while running Kani, that is now no longer the case. Other than this, I don't think Kani is impacted.

I think we used to see loop-unwinding information while running Kani, that is now no longer the case.

While I'm happy to see that, users may have depended on this output to see when CBMC is unwinding forever. So, I think we should at least point this change out in the CHANGELOG.md.
I would also suggest adding a Kani option that would turn on --verbosity 9 in case users want to restore the old behavior. What do you think?


Add v5/splunkpgx package to provide support for pgx/v5

Adds pgx v5 (5.4.3) alongside with v4 for compaotability. Issue #2406

Codecov Report
Patch coverage: 72.13% and project coverage change: -0.52% :warning:

Comparison is base (5c97f0f) 83.08% compared to head (ba708c2) 82.56%.

Additional details and impacted files
@@            Coverage Diff             @@
##             main    #2409      +/-   ##
==========================================
- Coverage   83.08%   82.56%   -0.52%
==========================================
  Files          81       82       +1
  Lines        3157     3218      +61
==========================================
+ Hits         2623     2657      +34
- Misses        467      486      +19
- Partials       67       75       +8

Flag
Coverage Δ

Linux
82.56% <72.13%> (-0.21%)
:arrow_down:

Windows
?

macOS
?

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

Files Changed
Coverage Δ

...mentation/github.com/jackc/pgx/v5/splunkpgx/sql.go
72.13% <72.13%> (ø)

... and 1 file with indirect coverage changes

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

I have updated CHANGELOG.md file by adding new change entry.


Make sure libGaudiCoreSvc.so is found by genconf

Fixes several dlopen failures on MacOsX of this sort:
WARNING: cannot load libGaudiCoreSvc.so for factory ApplicationMgr
WARNING: dlopen(libGaudiCoreSvc.so, 0x0009): tried: 'libGaudiCoreSvc.so' (no such file), '/usr/local/lib/libGaudiCoreSvc.so' (no such file), '/usr/lib/libGaudiCoreSvc.so' (no such file), '/Users/ganis/local/key4hep/build/k4FWcore/test/k4FWCoreTest/libGaudiCoreSvc.so' (no such file)
Setting LD_LIBRARY_PATH and similar does not work, but perhaps there is another way to fix it.
BEGINRELEASENOTES

Fixes several dlopen failures on MacOsX due to libGaudiCoreSvc.so not being found.
ENDRELEASENOTES

Hi Gerri, yes, I'm hoping this issue will be fixed upstream, see issue https://gitlab.cern.ch/gaudi/Gaudi/-/issues/251 .
Using the current working directory for the libraries is possible, but it has the downside that you would need to do this for all gaudi modules, so most key4hep packages as well, which seems cumbersome. https://github.com/key4hep/k4FWCore/pull/98 is an alternative fix that should work for everything, provided you are not using the system python, but an installation outside of /usr/bin.


chore(deps): update common-dev-assets digest to b53828e

This PR contains the following updates:

Package
Update
Change

common-dev-assets
digest
f31d84d -> b53828e

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
👻 Immortal: This PR will be recreated if closed unmerged. Get config help if that's undesired.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

:tada: This PR is included in version 2.2.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Add serial connector interface

Serial is more a means to an end, a serial port by itself doesn't do anything.
Streams are created by a protocol layer that uses the serial port, e.g. ELM327

So the ELM327 logic needs access to the OutputStream and InputStreams to send the commands to the ELM327 chip and receive the response.
It seemed to me that separating the protocol from connectivity to the serial port is a good thing, rather than having them intertwined.

I see.  I get the desire to separate opening/managing the {I,O} streams from a higher level device specific protocol layer.
Independent of that it feels that it would be better if SerialDevice wasn't required to have ~copies of the Topology stream-source methods.  No? I also wonder if the signature of the initializer and driver functions isn't extensible enough.  Will the two streams alone always be enough?
Imagine something like the following (thinking out loud)...
interface SerialDevice {
    OutputStream getOutputStream();
    InputStream getInputStream();
    // maybe other things later?
    void setInitializer(Runnable initializer);
    <T> Supplier<T> wrap(Supplier<T> driver);  // returned supplier doesn't call driver until after initializer is run
}

Topology t = ...;
SerialDevice sd = ...;
MyProtocol myProtocol = new MyProtocol(sd);  // calls sd.setInitializer()
TStream<JsonObject> s = t.poll(t, myProtocol.getSupplier(), 200, MILLISECONDS);
// where myProtocol.getSupplier() {
//              return sd.wrap( () -> { use sd.get{*}Stream() and create and return the tuple } )};

A serial port only has an input and an output I/O stream.
Like IotDevice, SerialDevice is a graph declare time construct, therefore it doesn't have InputStream and OutputStream instances, those are created at runtime. That's why I was passing them into the methods.
I'll think if it can be done some other way.

Changed to a function model.
Added WIP as I've only changed the interface at this point, need to verify it will work with the implementation.

ported over an implementation to the new style with no issue.


FW generalize auto takeoff

This PR refactors RunwayTakeoff to be used for all FW auto takeoff, which then simplifies the handling within the FW position controller.
This is based on the observation that hand launching larger aircraft require roughly the same phases as runway takeoff.
ACCELERATE (formerly CLAMPED_TO_RUNWAY for RunwayTakeoff)

no roll or pitch until min airspeed * scaling is reached
fixed heading

TAKEOFF

no roll, small pitch until we have enough ground clearance
fixed heading

CLIMBOUT

roll constrained to MAX_ROLL while navigating to takeoff point

FLY

proceed to takeoff waypoint normally

All runway specific functionality should be encapsulated within the FixedwingTakeoff class, with the defaults being appropriate for hand launch.
There should be no change to runway takeoff other than renamed params. Existing auto takeoff for small aircraft should be roughly the same as they quickly hit min airspeed after a throw. They'll now have heading hold (while under climbout diff), but that can be disabled. Hand launching larger heavier aircraft that require time to accelerate before climbout should be much more reliable with this change.
TODO

[x] match existing launch detection throttle behaviour
[ ] test runway takeoff
[ ] test hand launch
[ ] test hand launch with launchdetection
[ ] @AndreasAntener getYaw() takeoff in current heading direction idea
[x] modify navigator takeoff waypoint acceptance (see #3922)
[ ] launch detect rename to FW, maybe same group?
[x] update airspeed setpoint to calculate_target_airspeed(mission_airspeed) after climbout

-closes issue #3812

I believe this now incorporates all auto takeoff functionality. Moving on to testing.

This is still WIP, correct?

All the functionality of the 3 takeoff variations (regular, launch detect, runway) is now incorporated, it just needs way more testing.
I'll post logs of testing this over the coming weeks.

TODO: update airspeed setpoint to calculate_target_airspeed(mission_airspeed) after climbout

I've been thinking about how to gracefully handle failure (motor, esc, prop, etc) at take off. Instead of forcing a min pitch of 10 degrees couldn't we just force takeoff throttle (default max), speedweight 2.0, and normal pitch limits? TECS would handle setting pitch and climbout without being forced. If the motor failed though TECS would pitch down to maintain airspeed and the plane would land instead of stall and possibly crash.

We didn't find what you describe to work reliably. I would only want to remove the pitch limit against an extensive set of test flights proving this.

I would like to strongly recommend to test what you have here in a lot of flights before making any further changes. These things are hard to get right, and if you change too much without a lot of flying you can get yourself in a state where nothing works and its really hard to work out how it broke.

Will do. Thanks for the feedback.
On Sun, Mar 27, 2016, 06:17 Lorenz Meier<EMAIL_ADDRESS>wrote:

I would like to strongly recommend to test what you have here in a lot of
flights before making any further changes. These things are hard to get
right, and if you change too much without a lot of flying you can get
yourself in a state where nothing works and its really hard to work out how
it broke.
—
You are receiving this because you were assigned.
Reply to this email directly or view it on GitHub
https://github.com/PX4/Firmware/pull/3819#issuecomment-202032037

I had several very good test flights today. I still need to test launch detection and some edge cases.
TODO:

test hand launch
exhaustively test all FW_TO parameters

I'm waiting on a hobbyking bixler 3 (with landing gear) to test runway takeoff outside of HIL.

@dagar Where is this standing?

This is mostly waiting for me to actually go to the field and fly.
@AndreasAntener In the current runway_takeoff you check alt > RWTO_NAV_ALT to transition from TAKEOFF -> CLIMBOUT and then alt > FW_CLMBOUT_DIFF to transition from CLIMBOUT -> FLY. This is different than the other uses of FW_CLMBOUT_DIFF (altitude error). Is it intentional and something you want to keep? At the moment in this PR I'm using climbout_diff as described in the param (altitude error).
https://github.com/PX4/Firmware/blob/master/src/lib/runway_takeoff/RunwayTakeoff.cpp#L115

@dagar isn't it also used in your new takeoff as ground clearing altitude?

I changed it to climb out until altitude error < climbout_diff, but now I'm questioning what the best behaviour is. I wanted to avoid climbout diff meaning different things in different parts of the code.
https://github.com/PX4/Firmware/pull/3819/files#diff-2c7a94ff585bc8eee96f14706024779cR148

Ok, I always understood the climb out diff as absolute ground clearance but I'm not sure if that was the original intention (was implemented for takeoff that way though). Yes, maybe we need to separate that. I'm hoping we could then start to use the altitude error for more (violation as symptom for different failures)

I'll reopen this once I've had a few thorough flight tests with data and it's ready to be merged immediately.


Performance rule: size and % of base64 content

Size and % of base64 content should be low.


Relocatable arm A-53 binary.

Is your feature request related to a problem? Please describe.
My project requires a relocatable binary for ARM A53. Currently if I try to change the kernel offset, Address map, nothing seem to work.
Describe the solution you'd like
Ability to relocate the arm a53 elf file.
Describe alternatives you've considered
Relinking all the object files and libraries with a custom linker. But this seems strenuous.
Additional context
This is required to randomize the kernel load address. A security requirement.

https://github.com/zephyrproject-rtos/zephyr/issues/2746


Update winit to 22.0.0

22? We are at winit 0.29.8 (Winit 29.8)

sory, i mean latest winit

Ah, yeah there was a ton of incompatibility with latest winit, especially with dependencies. I'll try solving them and updating.


Warning: local() encountered an error (return code 1)

Hi, what could the source of the problem?
Beating the head against a wall
Fabric==1.14.0
fabricio==0.3.1
local: docker build --tag front:latest --pull --build-arg nginx_config_filename=local.conf .
Sending build context to Docker daemon  436.6MB
Step 1/15 : FROM centos:centos7
Get https://registry-1.docker.io/v2/: EOF
Warning: local() encountered an error (return code 1) while executing 'docker build --tag front:latest --pull --build-arg nginx_config_filename=local.conf .'
Traceback (most recent call last):
File "/usr/local/lib/python2.7/site-packages/fabric/main.py", line 757, in main
*args, **kwargs
File "/usr/local/lib/python2.7/site-packages/fabric/tasks.py", line 426, in execute
results[''] = task.run(*args, **new_kwargs)
File "/usr/local/lib/python2.7/site-packages/fabric/tasks.py", line 173, in run
return self.wrapped(*args, **kwargs)
File "/usr/local/lib/python2.7/site-packages/fabricio/tasks.py", line 368, in deploy
fab.execute(self.prepare, tag=tag, no_cache=no_cache)
File "/usr/local/lib/python2.7/site-packages/fabric/tasks.py", line 426, in execute
results[''] = task.run(*args, **new_kwargs)
File "/usr/local/lib/python2.7/site-packages/fabric/tasks.py", line 173, in run
return self.wrapped(*args, **kwargs)
File "/Users/myusername/Develop/chat-bot/frontend/fabfile.py", line 206, in prepare
use_cache=True,
File "/usr/local/lib/python2.7/site-packages/fabricio/init.py", line 74, in local
**kwargs
File "/usr/local/lib/python2.7/site-packages/fabricio/init.py", line 27, in _command
raise RuntimeError(result)
RuntimeError

I suppose your build image command ends up with an error. I’m not sure why you don’t see this error, maybe because of capture=True.
Try to execute image build command without Fabricio. You should see error message at least.

It fails with this task:
class FrontTasks(tasks.BuildDockerTasks):

    @fab.task(task_class=tasks.IgnoreHostsTask)
    def prepare(self, tag=None, no_cache=False):
        """
        prepare Docker image
        """
        options = Options([
            ('tag', str(self.image[tag])),
            ('no-cache', strtobool(no_cache)),
            ('pull', True),
            ('build-arg', 'nginx_config_filename=%s' % fab.env.get('nginx_config_filename', ''))
        ])
        fabricio.local(
            'docker build {options} {build_path}'.format(
                build_path=self.build_path,
                options=options,
            ),
            quiet=False,
            use_cache=True,
        )
        self.remove_obsolete_images()

It seems you mean to build an image with docker build

Problem solved with local building the image from the console and the problem that I see is using a cache


lbagent: deploy: 增加健壮性

这个 PR 实现什么功能/修复什么问题:
lbagents: deploy: check existence of pbId before create/update
ansibleserver: ansibleplaybooks: a way out on status chaos

是否需要 backport 到之前的 release 分支:

release/2.10.0

Codecov Report

Merging #2932 into master will decrease coverage by <.01%.
The diff coverage is 0%.

@@            Coverage Diff            @@
##           master   #2932      +/-   ##
=========================================
- Coverage    7.06%   7.06%   -0.01%
=========================================
  Files         477     477
  Lines       76396   76402       +6
=========================================
  Hits         5396    5396
- Misses      70548   70554       +6
  Partials      452     452

Flag
Coverage Δ

#aFlag
7.06% <0%> (-0.01%)
:arrow_down:

Impacted Files
Coverage Δ

pkg/compute/models/loadbalanceragents_deploy.go
0.37% <0%> (-0.01%)
:arrow_down:

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 5ce5e36...3e45f93. Read the comment docs.

/lgtm

/approve


No link to medium article from cover page

Hey,
if I try to click the "Read the story on Medium" button on the https://patternplate.github.io/ cover there is no link to go to. Related line is: https://github.com/patternplate/patternplate/blob/3c74a9f95dcce9d8631a37eee214beb318fa6ef3/packages/components/src/cover/index.js#L202
If I had found the article on medium, I would have created a PR 😅

Good catch! The article does not exist yet, so there is nothing link. I'll keep this around to remind ourselves.

Fixed via fed983ba89e321ab9e6d483d7e66d14d4b512f5a


Splitting off spec2vec

sonarcloud fails due to missing token; we should fix this after we transfer the repo to iomega


School Library Code Refactoring Completed

The project has been refactored on branch 'solid-refactor'
The SOLID principle was used

[ ] YAGNI, KISS, and DRY rules and Ruby style guide were respected.
[ ] Special attention was given to the "Single-responsibility Principle".
[ ] The role of main.rb is only to start the code and ask for user inputs (or to quit).
[ ] Some pieces of logic were extracted into a separate class(es).

All Fixed. Thanks.


Added reverse integer solution in C

I have added the reverse integer solution in C language and also updated the readme file.
I hope you will like it.
Thank you.

Repo excluded

@lucy2512 Please read the pinned issue to know more!


fix: highlighting improved for interactables with multiple collider

Description
Fixed the highlighting by running a own list which is not limited to a unique reference to the object. So each collider is handled separately and as long as there is at least one collider inside the snapzone its highlighted.
Testing
The way I tested this was with the box from the XR-CKD Demo Project which contains multiple collider. I also figgured out the problem actually occured more often when one Collider was completely surrounded by another one.

It works for me but, I have the issue that I can't reproduce the original issue anymore when I'm on develop.
I would love if more people can test it in VR, @aleksei-korolev, @Maxsiom, @Luphoxa.

Awesome! I just wanted to be sure! 👍

I was able to reproduce it in develop and not in this branch. Really nice!

:tada: This PR is included in version 1.4.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Hot Reload Validation

Why make this change?
This change fixes issue #2396
What is this change?
In order to validate the hot-reload, first, new logic was added to the RuntimeConfigLoader and FileSystemRuntimeConfigLoader, so when hot reload occurs, it updates the new states added to the loader which are isNewConfigDetected, isNewConfigValidated, and lastValidRuntimeConfig.
Once the states are updated, it will try to parse and validate the new RuntimeConfig, in the case that it fails at any step of the way, the hot-reloading process will be canceled and the RuntimeConfig file will be changed so that it uses the information from lastValidRuntimeConfig so that the user can still use their last configuration without any problems.
How was this tested?

[X] Integration Tests
[ ] Unit Tests

/azp run

/azp run

/azp run

/azp run

/azp run

This is great and the way that you update with the Last Known Good will close this bug here: https://github.com/Azure/data-api-builder/issues/2418
So you can added the closes tag for that issue to the PR description.