Can't  see colorbar in the FK plots!

The function seisplotFK does not include the color bar necessary for comparisons.

I believe this has been solved with #26 , so I'm closing this for now.

thanks for oppening issues reporting bugs, I really appreciate it!


fix: check extraEntropy according to the spec

#55

Length of Fp.bytes are for compatibility with libsecp256k1: https://github.com/bitcoin-core/secp256k1/blob/67214f5f7d8e0bdf193ceb1f47ba8277d1a0871a/src/secp256k1.c#L476
Do you need longer value for something, or this is just fixing spec non-compliance?

I'm moving from our lovely elliptic module...
For the EOS crypto 1 byte additional data is used. So I checked the spec and realized that it is not mandatory for additional data to be 32 bytes.
According to the comment from libsecp256k1 https://github.com/bitcoin-core/secp256k1/blob/67214f5f7d8e0bdf193ceb1f47ba8277d1a0871a/src/secp256k1.c#L477 additional 16 bytes may be appended too.

For the EOS crypto 1 byte additional data is used. So I checked the spec and realized that it is not mandatory for additional data to be 32 bytes.

if the byte is e.g. de, you can do this:<PHONE_NUMBER>000000000000000000000000000000000000000000000000000000de. Does this work?
With regards to 16-byte algorithm name: that's true.

Yes, it is possible to produce valid EOS signature by using<PHONE_NUMBER>0000000000000000000000000000000000000000000000000000de but not the same signature as original EOS code produces.
I think it is better to follow specification and check that extraEntropy is bytes but not check the size.

I agree with you.

but not the same signature as original EOS code produces

That's weird. I would have thought they are the same - which would have worked for now.

Could you add a test for this, please?

@mahnunchik ping

@paulmillr done

Yep, additional test may be added just to test different entropy sizes.

Ok, please add it and revert json change and we'll be good to go.

@paulmillr please check the changes


tensor & positional encoding on different devices in Summer when using 3D positional encodings with batch size = 1

Hi,
I'm using 3D positional encodings for pytorch in a (shifted window) transformer model. My model was trained with a batch size of 8. In testing, the positional encodings work fine with a batch size > 1. With batch_size = 1, however, the positional encoding is on device 'cpu' while my patch embedding is on device 'cuda:0', so the positional encoding can't be added to the patch embedding in the Summer class.
I naively fixed the issue by replacing: return tensor + penc with return tensor + penc.to(tensor.device) in torch_encodings.py (line 213). Is the idea of just forcing the positional encoding to be on the same device as the embedding valid, and should be added in the code maybe?
Best regards,
Tjade

Hi Tjade,
Thanks for discovering this! Yes, I think this is valid. If you want, feel free to send me a PR for this. I think it would be valid to add this for all of 1,2 and 3D methods.

Fixed in #41.


Rename key-store-path command line option

Rename the command line option --key-store-path as it is confusing since it implies that it is related to key stores. This is the key config directory and is for more than just keystore files. It is also similar in name the recently added keystore bulk loading command line options https://docs.web3signer.consensys.net/en/latest/Reference/CLI/CLI-Subcommands/#keystores-path.
Tasks

[ ] Keep old name as an alias and deprecate
[ ] New name

@james-prysm No decision has been made on what the name would change to. Was thinking --key-config-path would work well but that's not locked in yet. Will update this ticket once we decide on the new command line option name.

@james-prysm we went with --key-config-path but --key-store-path still works

awesome thanks for letting me know


Support "Update" without "Create" management policy combinations

What problem are you facing?
Suppose you want to extend functionality of a resource of which you should not be managing the lifecycle of. To extend functionality of this resource you may need to add some annotations as is common in Kubernetes.
A more concrete example is providing a Kubernetes service account with AWS credentials via IRSA. This requires creating an IAM Role with the required policies and adding an annotation to the service account to link it to the IAM Role. However, this service account is created via a helm chart and you do not want to take "ownership" of the resource.
The problem is deciding on the right supported combination of management policies for the service account resource. All combinations of Update require Create to also be given. But this is not in the scope of this composition, it is designed to only annotate the service account if it exists and should fail otherwise. We are assuming a pre-existing resource, and will try again later if it is missing, presumably when the helm chart is installed.
How could Crossplane help solve your problem?
Crossplane could solve this problem by allowing a combination of Observe and Update management policies so that the provider can correctly annotate the service account without creating it if it is missing. The managed resource should fail to sync if it is missing and therefore cause the containing composition to not be ready.

/fresh

Thanks @tvandinther for creating the issue, sorry for noticing it late. Seems like this is still relevant.
IMO it would make sense to add LateInitialize to the combination of management policies"
["Observe", "Update", "LateInitialize"] to fill up the spec.forProvider with the values observed(and not set) to avoid the Update overriding some fields if the spec is missing some fields.
The change should not be big:

update the policies list here with the desired combination
add an unit tests
hopefully test it in a provider

Adding this as a good-first-issue if somebody wants to contribute.


web-sys: required Cargo features aren't exhaustive

For example Window::fetch_with_str's requirement list only includes the Window feature but to actually get access to the  function, you need at least Window, Request, and Response.

Thanks for the report! This shouldn't actually require the Request and Response features though, that's a bug! It should be fixed in https://github.com/rustwasm/wasm-bindgen/pull/803


Feature/sisyfos mapping

Sisyfos mapping with labels and hide fader
Fix: removed ÆØÅ in var names and const

@olzzon why did you remove ÆØÅ? Why does it not work having them?

I´m still investigating, so far it looked like it was the problem in:
SisyfosSourceVært_1_ST_A = 'sisyfos_source_vært_1_st_a',
Will follow up

Are we only talking about variable names here? The label will contain ÆØÅ?
If so i suggest we follow a convention in variable names where Æ=E, Ø=O, Å=A


Switch status loosing sync

Hello, I have got last version alpha 0.5b installed and switch status gets lost every one and then, like now, showing off when it was on and no other interpreter switch it off (Alexa, smart life, no one touched the state).
What can I do to debug and solve this issue?

I had my device online for weeks, has the device a static ip adres?

@Xenomes yes, it is static ip address with a dhcp reservation

When the device is offline, is control through the tuya app still possible?

@Xenomes yes, tuya and also domoticz

Okay, thanks for that info. I will check the code that controls the offline state.

Device is on now, if I turn off through tuya app, in domoticz it stays on and these are the logs which are repeated every 10 seconds, no indication about the device :
2024-11-03 12:36:31.026 Tuyalocal: Pushing 'onHeartbeatCallback' on to queue
2024-11-03 12:36:31.077 Tuyalocal: Processing 'onHeartbeatCallback' message
2024-11-03 12:36:31.078 Tuyalocal: Acquiring GIL for 'onHeartbeatCallback'
2024-11-03 12:36:31.078 Tuyalocal: Calling message handler 'onHeartbeat' on 'module' type object.
2024-11-03 12:36:31.078 Tuyalocal: onHeartbeat called
2024-11-03 12:36:31.079 Tuyalocal: Update devices in Domoticz
2024-11-03 12:36:31.525 Tuyalocal: Acquiring GIL for 'onHeartbeatCallback'
2024-11-03 12:36:41.040 Tuyalocal: Pushing 'onHeartbeatCallback' on to queue
2024-11-03 12:36:41.090 Tuyalocal: Processing 'onHeartbeatCallback' message
2024-11-03 12:36:41.091 Tuyalocal: Acquiring GIL for 'onHeartbeatCallback'
2024-11-03 12:36:41.091 Tuyalocal: Calling message handler 'onHeartbeat' on 'module' type object.
2024-11-03 12:36:41.091 Tuyalocal: onHeartbeat called
2024-11-03 12:36:41.091 Tuyalocal: Update devices in Domoticz


Fix to work on Julia 0.5

sub(M, n, :) no longer returns a matrix; use sub(M, n:n, :) instead.
Also relax test tolerance in test/svdl.jl

Coverage increased (+0.4%) to 86.642% when pulling 62510b95e6ff764b55b55a994fce740c04cc22ee on cjh/fix0.5 into 1b44f59971f60a5d621cf7ee52a772e8da871ab7 on master.

Coverage increased (+0.4%) to 86.642% when pulling 62510b95e6ff764b55b55a994fce740c04cc22ee on cjh/fix0.5 into 1b44f59971f60a5d621cf7ee52a772e8da871ab7 on master.

Current coverage is 86.64% (diff: 100%)

Merging #81 into master will increase coverage by 0.37%

@@             master        #81   diff @@
==========================================
  Files            17         17
  Lines          1092       1093     +1
  Methods           0          0
  Messages          0          0
  Branches          0          0
==========================================
+ Hits            942        947     +5
+ Misses          150        146     -4
  Partials          0          0

Powered by Codecov. Last update 1b44f59...62510b9

In #77 there is a patch for this, using view in v.0.5 and sub in v.0.4

Or use Compat.view, much better for bisecting than an imprecise VERSION cutoff.

Closing in favor of #82


Unable to configure API Key for Lookup separately from IP Lookup

Given a lookup service like Google, which does not provide IP Lookup services. And given an IP Lookup service like Abstract, which does not provide Lookup services. There appears to be no official way to configure the paid API key(s) for both services.
Is there currently any way to configure API keys separately for API Lookup and Lookup services?

Yes, you can set any lookup-specific values for all config options by using the lookup's name as a key in the config hash. See here for an example: https://github.com/alexreisner/geocoder#configuring-multiple-services

This is great. Thanks for the help! I stopped too soon in the README at Please see lib/geocoder/configuration.rb for a complete list of configuration options. In this case, the following was implemented and worked perfectly:
Geocoder.configure(
  lookup: :google,
  ip_lookup: :abstract_api,
  google: {
    api_key: "abc1234",
  },
  abstract_api: {
    api_key: "def5678",
  }
)


set user detail

hey! hope you be well!
I am using crisp: ^0.1.6 and my flutter version is 2.2.0
I send user detail in CrispMain() but I receive the message as a visitor
what should I do?
CrispView(
crispMain: CrispMain(
websiteId: 'test',
user: CrispUser(
avatar: 'test',
email<EMAIL_ADDRESS>nickname: 'test',
phone: '5555',
)))
thank you.

Hey! I hope you too! Sorry for the delay!
I just tested, it's working as described on the docs. Now you can also set more options with setSessionData too.


PR for fix #206

Fix: https://github.com/react-community/create-react-native-app/issues/206
Expo's extra field for any configs: https://docs.expo.io/versions/v16.0.0/guides/configuration.html#extra

thanks!


How to terminate token process if user exits authentication page?

So in my web app I'm trying to account for the possibility that a user exits the Spotify authentication page without authenticating. How do I terminate the process? I have an "if token ... else return false" statement for the token but it doesn't seem to get there, it just stays running.

Assuming you are using authorization code: the user is unauthorized until he login & and give your application the authorization to access the scopes. https://tools.ietf.org/html/rfc6749#section-1.3.1

@stephenchou indeed the default is that if you do the following it will prompt and block if the spotipy authentication window is closed:
auth_manager = spotipy.oauth2.SpotifyOAuth()
spotify = spotipy.Spotify(auth_manager=auth_manager)

spotify.me()

To prevent prompting what you want to do is call auth_manager.get_access_token(code) before calling spotify.me(). A good example that does this is the API example https://github.com/plamere/spotipy/blob/master/examples/app.py where each action is separate and therefore won't block the main process

@stephanebruckert Thanks for your response. I forgot to mention that I'm using the "prompt_for_user_token" function and it doesn't seem to be returning false when I exit the authorization webpage without authenticating. Should I avoid using that then?

@StephenChou do you mean that it behaves as expected with auth_manager but doesn't with prompt_for_user_token?

@stephanebruckert Haven't tried auth manager yet, was hoping that I could possibly still use prompt_for_user_token, which doesn't seem to be hitting my false condition when I exit the authentication page. I guess I should probably try auth_manager then.

Yeah I doubt it will be any different with the auth_manager. If the authentication page is closed, I can't see how the python app could know about it because nothing is sent to the redirect URI. If this is a problem for you I really suggest you do something similar to the API example

Your solution is here, closing


ffmpeg: bump to v6.0

Description

Bump ffmpeg from v5.1 to v6.0
Screenshot

Issues Fixed or Closed

Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[x] Dependency update (updates to dependencies)
[ ] Documentation update (changes to documentation)
[x] Repository update (changes to repository files, e.g. .github/...)

Checklist

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[ ] I have commented my code, particularly in hard-to-understand areas
[ ] I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates
LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

[ ] I want maintainers to keep my branch updated

I tested the artifact from the latest run against nightly; software and amfenc appear to work fine, but I only tested on Windows 11 in SDR.

I think we need to also update 02-idr-on-amf.patch to cover amf_av1.c

I think we need to also update 02-idr-on-amf.patch to cover amfenc_av1.c

I've updated patch 01 (amf hdr) and 05 (qsv) with your suggested changes, but 02 (amf idr insertion) looks more complicated to implement.
The AV1 frame types seem different, and I'm not certain how to map the values to the traditional I/B/P/IDR/SKIP frames. The header insertion logic also seems more complicated (with different alignment types), so I'm not 100% certain how to implement the necessary changes.

Leaving these notes here so we don't forget:
For FFmpeg 6.1, we'll need to also change preanalysis -> preencode in our options dict, since upstream FFmpeg changed the semantics of the existing option in https://github.com/FFmpeg/FFmpeg/commit/f593dc98bfe4196ad60510008d43764e526d8cb9
I believe the QSV encoders also gained a remote_gaming preset which we should probably use too.

The AMF colourspace patch has also been updated to v3 (which includes av1 support): https://patchwork.ffmpeg.org/project/ffmpeg/list/?series=9415

Testing progress:

[x] QSV leak fix verified
[x] Windows AMD H.264+HEVC
[x] Windows AMD AV1
[x] Windows Intel H.264+HEVC
[x] Windows Intel AV1
[x] Linux VAAPI H.264+HEVC
[ ] Linux VAAPI AV1
[ ] Linux NVENC H.264+HEVC
[ ] Linux NVENC AV1

I'm satisfied that this build generally works. Let's merge this and we can perform final testing on the PR to the Sunshine repo.


Allow current_spree_user to be specified before trying to find one.

Thank you very much ! Spree and Refinery are now working together, it's a beautiful day and not a joke :)


 Everything had been working prior to the update.
The error reads is re;ated to
cannot import name 'QueryTool' from 'griptape.tools'
the complete traceback reads
Traceback (most recent call last):
File "S:\ComfyUI_windows_portable\ComfyUI\nodes.py", line 1993, in load_custom_node
module_spec.loader.exec_module(module)
File "", line 940, in exec_module
File "", line 241, in call_with_frames_removed
File "S:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-Griptape_init.py", line 14, in
from .nodes.agent.CreateAgent import CreateAgent
File "S:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-Griptape\nodes\agent\CreateAgent.py", line 1, in
from .BaseAgent import BaseAgent
File "S:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-Griptape\nodes\agent\BaseAgent.py", line 2, in
from griptape.tools import QueryTool, VectorStoreTool
ImportError: cannot import name 'QueryTool' from 'griptape.tools' (S:\ComfyUI_windows_portable\python_embeded\Lib\site-packages\griptape\tools_init_.py)
Cannot import S:\ComfyUI_windows_portable\ComfyUI\custom_nodes\ComfyUI-Griptape module for custom nodes: cannot import name 'QueryTool' from 'griptape.tools' (S:\ComfyUI_windows_portable\python_embeded\Lib\site-packages\griptape\tools_init_.py)

Can you try unloading and reloading the nodes? It sounds like griptape isn’t updating properly.
Let me know if this works!

Awesome, thanks! 👍


Keep scrollback buffer when clearing.

I prefer to have this plugin keep the scrollback buffer when clearing the screen.
To do so I added the -x flag to the clear command on line 16 of almostontop.plugin.zsh.
Now after every command the screen is cleared but I am still able to access the outputs of previous commands by scrolling up.

Hello,
What does -x flag do? The reason I'm asking, I could see output of previous commands by scrolling up by default.

Interesting. For me, the clear command deletes it from the scrollback buffer so I can't scroll up to see the previously executed commands. I am using the xfce4-terminal app, so I assume that may be the reason.
From the clear man page:
OPTIONS
...
       -x   do not attempt to clear the terminal's scrollback buffer using  the
            extended “E3” capability.

So by using clear -x instead of clear it keeps the scrollback buffer for me.

See linked changes. It covers your case.


[joy-ui] In the Next.js app router example, card overflow component is not rendered as per demo

Duplicates

[X] I have searched the existing issues

Latest version

[X] I have tested the latest version

Steps to reproduce 🕹
Link to live example: https://codesandbox.io/p/github/jamesxv7/joy-ui-nextjs-ts/
Steps:

Download the example repo, joy-ui-nextjs-ts, from Core.
Install and add a FAQ card component from the demo to the page.tsx
Expected to have an overflow blue background but instead a padding is shown around the blue area

Current behavior 😯

Expected behavior 🤔

Context 🔦
Using Next.js 13 App router example
Your environment 🌎

npx @mui/envinfo
    System:
    OS: Windows 10 10.0.22000
  Binaries:
    Node: 18.15.0 - C:\Program Files\nodejs\node.EXE
    Yarn: Not Found
    npm: 9.5.0 - C:\Program Files\nodejs\npm.CMD
  Browsers:
    Chrome: Not Found
    Edge: Spartan (44.22000.120.0), Chromium (116.0.1938.69)
  npmPackages:
    @emotion/react: latest => 11.11.1
    @emotion/styled: latest => 11.11.0
    @mui/base:  5.0.0-beta.13
    @mui/core-downloads-tracker:  5.14.7
    @mui/joy: latest => 5.0.0-beta.4
    @mui/private-theming:  5.14.7
    @mui/styled-engine:  5.14.7
    @mui/system:  5.14.7
    @mui/types:  7.2.4
    @mui/utils:  5.14.7
    @types/react: latest => 18.2.21
    react: 18.x => 18.2.0
    react-dom: 18.x => 18.2.0
    typescript: latest => 5.2.2

I have the same issue. But if I force use client it works fine

Thanks for reporting the issue. The CardOverflow looks for data-parent to stretch itself to fill the Card. It seems like using Component.muiName does not work with app router.
I will try to fix this with plain CSS.

@siriwatknp I'm using Vite without SSR and the Overflow is also not working there.


cn = ChunkNorris() should be cn = ChuckNorris()

Hey Keda87,
The title describes the issue in the README.md example usage code you have.
Thanks for creating this!
RP

Hi @ryanpoplin , thank you to let me know.
it fixed now


Why webpack load slow and why load js before css

@QiyuLi
Webpack, in the development model, may build slow because there may be some others' debug tools.
There is a way to load basic css at the backend in order to fix the pure html before loading the css. This need to do some research.

MERN officials is also experiencing slow build/rebuild. (3 minutes for them)
The reason is the debug tool and webpack need to go through all files from server-side.
I suggest improving this later.

Agree with you.
But one thing, we need to find a solution. After go to the home page, there several seconds show pure html no css.


How can i use this project?

What steps did you take and what happened:
Hi Team, I can't find any use-case for this project? could you share me a example how to use it?
What did you expect to happen:
Anything else you would like to add:
[Miscellaneous information that will assist in solving the issue.]
Environment:

Cluster-api version:
CAPM3 version:
IPAM version:
Minikube version:
environment (metal3-dev-env or other):
Kubernetes version: (use kubectl version):

/kind bug

/kind question

/triage accepted
So as a starting point @matthewei  I would recommend reading this https://book.metal3.io/ipam/introduction.
@peppi-lotta  I have heard that you are doing comparison between IPAM and CAPI-IPAM , could you please comment here whether you think Metal3-IPAM will remain relevant or should @matthewei  focus on CAPI IPAM more ?

ItCAPI-IPAM is very similar to ip-address-manager and has much of the same code. These might be some issue with cluster-api's move when performed with their IPAM in use. I'm but discussing with the developers to solve it. Metal3 could be moving to use CAPI's IPAM if these problems are solved. So I think it might be wiser to focus on CAPI's IPAM.

@peppi-lotta you mean we are ready to abandon this project?

@peppi-lotta you mean we are ready to abandon this project?

@peppi-lotta was referring to Metal3's own IPAM implementation. There is an ongoing evaluation of our own IPAM implementation that was created way before CAPI had an IPAM implementation, but if the CAPI implementation would fulfill all of the Metal3's needs then there is no reason to maintain our own.

@peppi-lotta you mean we are ready to abandon this project?

@peppi-lotta was referring to Metal3's own IPAM implementation. There is an ongoing evaluation of our own IPAM implementation that was created way before CAPI had an IPAM implementation, but if the CAPI implementation would fulfill all of the Metal3's needs then there is no reason to maintain our own.

yes, i see

/close


feat: add compile_inductive% and compile_def% commands

Add a #compile inductive command to compile the recursors of an inductive type, which works by creating a recursive definition and using @[csimp].

A revival of #1806 with a branch on the mathlib4 repo.  cc @cppio @rwbarton from the old PR

Could you summarize how this PR differs from the previous one?

Could you summarize how this PR differs from the previous one?

Merged master
Addressed all review comments from #1806
Add go-to-definition support for the identifier
Added a bunch of #compile commands, removing noncomputable porting notes along the way
Removed import Mathlib from the test

The reason I made a new one is because I didn't want to push to @cppio's master branch.

Last time I checked, Leo had a concern regarding compiled recursors that the type signature does not reflect the correct laziness / order of operations. Could you add documentation and/or a test which indicates what evaluation order these inductives have? My guess is that e.g. List.rec will evaluate the nil case unconditionally and all the other cases from the bottom up, although you can work around this by using the recursor at type Unit -> A instead of A.

I've added a warning to the file.  I'm not sure if Unit → A would help, since inlining happens after replacing the recursor.

Here's a demonstration:

def matchFoo : ℕ → ℕ
  | 0 => dbg_trace "Z"; 0
  | a + 1 => dbg_trace "A:{a}"; (dbg_trace "B:{a}"; matchFoo a) + (dbg_trace "C:{a}"; 1)

def recFoo : ℕ → ℕ :=
fun n => @Nat.rec (fun _ => ℕ) (dbg_trace "Z"; 0)
  (fun a as => dbg_trace "A:{a}"; (dbg_trace "B:{a}"; as) + (dbg_trace "C:{a}"; 1)) n

def recUnitFoo : ℕ → ℕ :=
fun n => @Nat.rec (fun _ => Unit → ℕ) (fun _ => dbg_trace "Z"; 0)
  (fun a as _ => dbg_trace "A:{a}"; (dbg_trace "B:{a}"; as ()) + (dbg_trace "C:{a}"; 1)) n ()

#eval matchFoo 5   -- A:4 B:4 A:3 B:3 A:2 B:2 A:1 B:1 A:0 B:0 Z C:0 C:1 C:2 C:3 C:4
#eval recFoo 5     -- Z A:0 B:0 C:0 A:1 B:1 C:1 A:2 B:2 C:2 A:3 B:3 C:3 A:4 B:4 C:4
#eval recUnitFoo 5 -- A:4 B:4 A:3 B:3 A:2 B:2 A:1 B:1 A:0 B:0 Z C:0 C:1 C:2 C:3 C:4

matchFoo is what you get with the equation compiler, this is the desired evaluation order, evaluating A:4 B:4, then the n=3 recursive call, then C:4.
recFoo is what is implemented in this PR with a basic use of Nat.rec: we first evaluate the n=3 recursive call, then A:4 B:4 C:4 at the end (resulting in an overall bottom up evaluation order).
recUnitFoo is the workaround: use Nat.rec as in this PR, but with a motive of Unit -> Nat instead, and introduce a fun _ => in each inductive case and a () on each occurrence of the IH in the closure. This restores the desired evaluation order, but it is unlikely we can do this transformation automatically unless we have access to the expression itself and some kind of macro expansion. We could still use it manually, however.

!bench

I've contributed significantly to this PR so I'm not sure I am a good reviewer at this point, but the perf results look good (ignore the wall of red, which is comparing against the wrong commit, the bit at the end is the correct comparison and it is basically perf-neutral), the implementation looks good to me, and this issue keeps coming up in the port.
bors r+


Getting below error while building flashlight (Bug ??)

I successfully installed all the dependencies and tried to build the flashlight for building and installing wav2letter. But found below issue. Please help me regarding the same.
manoj@office-magi-ubuntu:~/Alugha/flashlight/build$ make -j1
[  1%] Built target fl-libraries
[  1%] Performing update step for 'cereal'
[  1%] Performing configure step for 'cereal'
loading initial cache file /home/manoj/Alugha/flashlight/build/cereal/tmp/cereal-cache-Release.cmake
-- Configuring done
-- Generating done
-- Build files have been written to: /home/manoj/Alugha/flashlight/build/cereal/src/cereal
[  1%] Performing build step for 'cereal'
[  1%] No install step for 'cereal'
[  1%] Completed 'cereal'
[  1%] Built target cereal
[  1%] Building CXX object CMakeFiles/flashlight.dir/flashlight/distributed/backend/cpu/DistributedBackend.cpp.o
/home/manoj/Alugha/flashlight/flashlight/distributed/backend/cpu/DistributedBackend.cpp:18:10: fatal error: gloo/mpi/context.h: No such file or directory
   18 | #include <gloo/mpi/context.h>
      |          ^~~~~~~~~~~~~~~~~~~~
compilation terminated.
make[2]: *** [CMakeFiles/flashlight.dir/build.make:505: CMakeFiles/flashlight.dir/flashlight/distributed/backend/cpu/DistributedBackend.cpp.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:1032: CMakeFiles/flashlight.dir/all] Error 2
make: *** [Makefile:141: all] Error 2
manoj@office-magi-ubuntu:~/Alugha/flashlight/build$

Thanks and Regards,
Manoj

did you install all dependencies before? cc @avidov @jacobkahn

Hi Manoj,
Is this on latest version? if not, please share the version (git SHA) that you are using and I'll try to replicate.

@manojmsrit see https://github.com/facebookresearch/flashlight/issues/69. Add USE_MPI=ON when you're running cmake when building/installing Gloo.


Script as Create for stored procedures is failing with error in ADS for MySQL extension.

Azure Data Studio Version: 1.40.0 insider
OS Version: Edition Windows 10 Pro

Hi Team,
User is facing an error thrown by ADS while using script as create for procedures using MySQL Extension.
More details are in the issue opened in MySQL extension repo:
https://github.com/microsoft/azuredatastudio-mysql/issues/81
In the issue MySQL logs are attached. From logs I can see that scripting/script operation is successful.
Still, it is failing in ADS mentioning that no script is returned.
2022-10-17 18:26:44,470 INFO Received request id=8 method=scripting/script
2022-10-17 18:26:44,528 INFO ResponseSuccess message sent id=8 method=None
Steps to Reproduce:

Mentioned in the issue

resolved at users end


lefthook: 1.7.14 -> 1.7.15

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/evilmartians/lefthook/releases.
meta.description for lefthook is: Fast and powerful Git hooks manager for any type of projects
meta.homepage for lefthook is: https://github.com/evilmartians/lefthook
meta.changelog for lefthook is: https://github.com/evilmartians/lefthook/raw/v1.7.15/CHANGELOG.md
Updates performed

Golang update

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 1.7.15 with grep in /nix/store/alpb3f7hcfq59szi6nc8lrmq479fbbvn-lefthook-1.7.15
found 1.7.15 in filename of file in /nix/store/alpb3f7hcfq59szi6nc8lrmq479fbbvn-lefthook-1.7.15

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

2 total rebuild path(s)

2 package rebuild(s)

First fifty rebuilds by attrpath

lefthook

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/alpb3f7hcfq59szi6nc8lrmq479fbbvn-lefthook-1.7.15 \
  --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 lefthook https://github.com/r-ryantm/nixpkgs/archive/713cbd6fa047a5269148d9dfd1f51beb68c2b286.tar.gz

Or:
nix build github:r-ryantm/nixpkgs/713cbd6fa047a5269148d9dfd1f51beb68c2b286#lefthook

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/alpb3f7hcfq59szi6nc8lrmq479fbbvn-lefthook-1.7.15
ls -la /nix/store/alpb3f7hcfq59szi6nc8lrmq479fbbvn-lefthook-1.7.15/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.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

lefthook

Maintainer pings
cc @AndersonTorres 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


Make 0.0.0, initialize documentation structure based on readthedocs, add badges to README

This PR make a structure of docs, but did not add any meaningful contents into it.
The existence of docs will motivate us to carefully add our docstring.
After this PR, we have (almost) all structure of components in the repo, along with the package itself:

.github
tests
examples
docs

@kdund I regretted. In this PR, only the structure of the documentation is added. The content needs a lot more effort and I do not want to delay the release further. You might notice that HISTORY is very crowded now: https://github.com/XENONnT/alea/blob/777ef9a17f4dc5af41c9a6bf7818da8a859b61da/HISTORY.md
The good news is that the badges work: https://github.com/XENONnT/alea/blob/777ef9a17f4dc5af41c9a6bf7818da8a859b61da/README.md The DOI and pypi badges need the new release. I hope they look fine after the release.


"A general error occurred that is not covered by a more specific error code" while Set-CimInstance for Multi app kiosk

I tried provisioning multi app kiosk for our store.
I tried this command:
$namespaceName="root\cimv2\mdm\dmmap"
$className="MDM_AssignedAccess"
$obj = Get-CimInstance -Namespace $namespaceName -ClassName $className
Add-Type -AssemblyName System.Web
$obj.Configuration = [System.Web.HttpUtility]::HtmlEncode(@"
<?xml version="1.0" encoding="utf-8" ?>
<AssignedAccessConfiguration
xmlns="http://schemas.microsoft.com/AssignedAccess/2017/config"
xmlns:win11="http://schemas.microsoft.com/AssignedAccess/2022/config">
    <Profiles>
        <Profile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}">
            <AllAppsList>
                <AllowedApps>
                    <App AppUserModelId="Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge"/>
                </AllowedApps>
            </AllAppsList>
            <win11:StartPins>
                <![CDATA[
                { "pinnedList":[
                    { "appUserModelId":"Microsoft.MicrosoftEdge_8wekyb3d8bbwe!MicrosoftEdge" }
                ] }
                ]]>
            </win11:StartPins>
            <Taskbar ShowTaskbar="true"/>
        </Profile>
    </Profiles>
    <Configs>
        <Config>
            <Account>KioskUser</Account>
            <DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}"/>
        </Config>
    </Configs>
</AssignedAccessConfiguration>
"@)

Set-CimInstance -CimInstance $obj

And I got this error:
Set-CimInstance : 보다 구체적인 오류 코드가 적용되지 않는 일반 오류가 발생했습니다. (A general error occurred that is not covered by a more specific error code.)
위치 줄:1 문자:1
+ Set-CimInstance -CimInstance $obj
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (MDM_AssignedAcc..../Vendor/MSFT"):CimInstance) [Set-CimInstance], CimExce
   ption
    + FullyQualifiedErrorId : MI RESULT 1,Microsoft.Management.Infrastructure.CimCmdlets.SetCimInstanceCommand

I tried It on multiple devices and multiple versions of Windows. Of course, I updated Windows to latest version, even reinstalled with latest ISO.
At first I tried multiple apps, but posted XML is single, because Just I wanted know what is wrong. But AllowedApps was not the problem.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: a6eac98f-6a12-c1ae-1ed3-485ac97e8fb3
Version Independent ID: a6eac98f-6a12-c1ae-1ed3-485ac97e8fb3
Content: Set up a multi-app kiosk on Windows 11 - Configure Windows
Content Source: windows/configuration/lock-down-windows-11-to-specific-apps.md
Product: windows-client
Technology: itpro-configure
GitHub Login: @lizgt2000
Microsoft Alias: lizlong

It suddenly fixed after reboot many time.

As noted in this page, the command should work in Windows 10. However, It doesn't work at my multiple Windows 10 devices. I used command that copied from linked page, but not works. Is that document wrong?

We found out that the error is caused by a missing update "Windows Configuration Update", it would only run after enabling the 'Get updates first' setting in Windows Updates.
Attached an example of what we got it to work with.
Injecteer kiosk mode.txt
We ended up removing the Users group and adding the user to the guest group, though it will still cause some trouble here because they won't be able to download any files for (for ex.) Citrix. We did expect it would wipe the browsing history etc, but it didn't do anything.

After googling for a long time I found a rant on a website that summarizes my past few days too, exactly the same issues we've had in this regard: https://www.aftersixcomputers.com/i-loath-bad-documentation/

Hello
In my test environment I could see the same error situation.
After a long search, I realized that the "Multi app kiosk" will only be activated with the "optional non-security preview release (27th June) for Windows 11, version 22H2".
Source: https://www.anoopcnair.com/first-windows-11-controlled-feature-rollout/
However, the "Moments 3 feature" can already be activated for tests with the "Vivetool".
Source: https://pureinfotech.com/install-moment-3-feature-drop-update-windows-11/
After activation ...
vivetool /enable /id:41655236
...and a restart I was able to set the required configuration...
<![CDATA[{ "pinnedList":[     { "desktopAppLink": "%ALLUSERSPROFILE%\\Microsoft\\Windows\\Start Menu\\Programs\\Remote Desktop Connection.lnk" },     { "desktopAppLink": "%ALLUSERSPROFILE%\\Microsoft\\Windows\\Start Menu\\Programs\\Restart.lnk" },     { "desktopAppLink": "%ALLUSERSPROFILE%\\Microsoft\\Windows\\Start Menu\\Programs\\Shutdown.lnk" }     ] } ]]>
...without any problems.

I'm still not able to add multiapp kiosk on windows 11, latest update.
Can anyone provide a bare minimum working XML? Cause I'm starting to think that this won't work whatsoever

Hello, i got this to work on the latest Windows 11 build, building from the Sample Assigned Access XML that Microsoft has provided for Win 11.
To get it to work with the default sample that Microsoft has provided:
<Config>
      <Account>MultiAppKioskUser</Account>
      <DefaultProfile Id="{9A2A490F-10F6-4764-974A-43B19E722C23}"/>
    </Config>

You have to create a user in computer management beforehand named "MultiAppKioskUser"
In my case i wanted an autologin feature to work. So i instead went with this:
<Config>
      <!--AutoLogon account-->
      <AutoLogonAccount />
      <DefaultProfile Id="{814B6409-8C51-4EE2-95F8-DB39B70F5F68}" />
    </Config>

This automatically creates the kioskuser and the autologin actually works.

To make it easier for you to submit feedback on articles on learn.microsoft.com, we're transitioning our feedback system from GitHub Issues to a new experience.
As part of the transition, this GitHub Issue will be moved to a private repository. We're moving Issues to another repository so we can continue working on Issues that were open at the time of the transition. When this Issue is moved, you'll no longer be able to access it.
If you want to provide additional information before this Issue is moved, please update this Issue before December 15th, 2023.
With the new experience, you no longer need to sign in to GitHub to enter and submit your feedback. Instead, you can choose directly on each article's page whether the article was helpful. Then you can then choose one or more reasons for your feedback and optionally provide additional context before you select Submit.
Here's what the new experience looks like.
Note: The new experience is being rolled out across learn.microsoft.com in phases. If you don't see the new experience on an article, please check back later.
First, select whether the article was helpful:

Then, choose at least one reason for your feedback and optionally provide additional details about your feedback:

Article was helpful
Article was unhelpful

Finally, select Submit and you're done!


Verify accuracy of PyPI download tracking

This provides some info on how to track visits and clones: https://opensource.guide/metrics/

We are using this guide with bigquery to track downloads:
https://packaging.python.org/guides/analyzing-pypi-package-downloads/
For now, we are tracking 2 download numbers:

via pip only
via all

Will continue to track both metrics over time.


(maint) Amazon linux reports majrelease as '2018'

Currently, On AmazonLinux, every puppet run throws this warning message:
Warning: Found multiple default providers for package: yum, pip3, puppet_gem; using yum

Here is the os facts hash on Amazon Linux:
# facter -p os
{
  architecture => "x86_64",
  family => "RedHat",
  hardware => "x86_64",
  name => "Amazon",
  release => {
    full => "2018.03",
    major => "2018",
    minor => "03"
  },
  selinux => {
    enabled => false
  }
}

Here is the os facts hash on Amazon Linux 2:
# facter -p os
{
  architecture => "x86_64",
  family => "RedHat",
  hardware => "x86_64",
  name => "Amazon",
  release => {
    full => "2",
    major => "2"
  },
  selinux => {
    enabled => false
  }
}

Can one of the admins verify this patch?

first time contributor! 🎉

I made another push to try and fix the failing test for an improperly formatted commit message 😅

Hi @cabrinha ! Thank you for your contribution!
It looks like you were able to update the commit, but git got a little confused. You'll want to squash your commits (git rebase -i HEAD~2) .
That'll open an editor with the following
  1 pick 99589ac4d4 (maint) Amazon linux reports majrelease as '2018'
  2 pick e0050b0030 Amazon linux reports majrelease as '2018'

Change the second pick to either f or fixup, save the change, and exit the file.
Once you've squashed your commits, you'll have to force push to your development branch (git push -f cabrinha amazon-linux). You may have to change cabrinha to whatever your own fork of the puppet repo is named.
Let me know if that makes sense, or if you'd like more git guidance!
I also have two more questions for you. We have code for Amazon Linux to default to systemd: https://github.com/puppetlabs/puppet/commit/763d01a2083efccada8d933dc69d944ce99b333c and https://github.com/puppetlabs/puppet/commit/621e4d00bef367b8ca9e01e0222518affd0800d0
I'm personally not super familiar with Amazon Linux, but I'd like to get confirmation which package manager we should be defaulting to here. I'll try to get review from someone with more knowledge in this area than me.
Finally, we probably want to also add tests. See the above commits I linked for test examples.
@puppetlabs/platform-os can you weight in on this PR? Which package management system should we be using on Amazon Linux?

Waiting for CLA signature by @cabrinha
@cabrinha - We require a Contributor License Agreement (CLA) for people who contribute to Puppet, but we have an easy click-through license with instructions, which is available at https://cla.puppet.com/
Note: if your contribution is trivial and you think it may be exempt from the CLA, please post a short reply to this comment with details. http://docs.puppet.com/community/trivial_patch_exemption.html

Hi @cabrinha ! Thank you for your contribution!
It looks like you were able to update the commit, but git got a little confused. You'll want to squash your commits (git rebase -i HEAD~2) .
That'll open an editor with the following
  1 pick 99589ac4d4 (maint) Amazon linux reports majrelease as '2018'
  2 pick e0050b0030 Amazon linux reports majrelease as '2018'

Change the second pick to either f or fixup, save the change, and exit the file.
Once you've squashed your commits, you'll have to force push to your development branch (git push -f cabrinha amazon-linux). You may have to change cabrinha to whatever your own fork of the puppet repo is named.
Let me know if that makes sense, or if you'd like more git guidance!

Thanks for the help @melissa! I know git rebases and merges can get pretty messy sometimes. I think I've fixed the commit now.

I also have two more questions for you. We have code for Amazon Linux to default to systemd: 763d01a and 621e4d0
I'm personally not super familiar with Amazon Linux, but I'd like to get confirmation which package manager we should be defaulting to here. I'll try to get review from someone with more knowledge in this area than me.
Finally, we probably want to also add tests. See the above commits I linked for test examples.
@puppetlabs/platform-os can you weight in on this PR? Which package management system should we be using on Amazon Linux?

The default package manager for Amazon Linux 1 and 2 should be yum.
I think we should be adding more to the :operatingsystemmajrelease => [] array as well. Under the "Release Notes" section of Amazon Linux AMI documentation, the releases range from 2011 to 2018 for Amazon Linux 1. Amazon Linux 2 reports it's operatingsystemmajrelease simply as '2'.
Amazon Linux 1 doesn't use systemd, it uses upstart/sysvinit. Amazon Linux 2 uses systemd.

Waiting for CLA signature by @cabrinha
@cabrinha - We require a Contributor License Agreement (CLA) for people who contribute to Puppet, but we have an easy click-through license with instructions, which is available at https://cla.puppet.com/
Note: if your contribution is trivial and you think it may be exempt from the CLA, please post a short reply to this comment with details. http://docs.puppet.com/community/trivial_patch_exemption.html

I went ahead and clicked through the prompts. Let me know if anything else is needed.

CLA signed by all contributors.

Oh my gosh, I can't believe I mixed up service providers and package managers... Sorry about that confusion.
I'm having trouble getting eyes on this from the team that normally maintains these platform specific types & providers. That being said, your link to the Amazon Linux AMI documentation looks sufficient. You've convinced me.
It might be good to add a little more disambiguation between Amazon Linux and Redhat. Is there any reason we can't add a new, more specific default? Something like defaultfor :osname => :amazon, :operatingsystemmajrelease => [2018]. Again, I've never actually looked at the facter output on an AL box, so this might not be quite the right syntax.

Oh my gosh, I can't believe I mixed up service providers and package managers... Sorry about that confusion.
I'm having trouble getting eyes on this from the team that normally maintains these platform specific types & providers. That being said, your link to the Amazon Linux AMI documentation looks sufficient. You've convinced me.
It might be good to add a little more disambiguation between Amazon Linux and Redhat. Is there any reason we can't add a new, more specific default? Something like defaultfor :osname => :amazon, :operatingsystemmajrelease => [2, 2018]. Again, I've never actually looked at the facter output on an AL box, so this might not be quite the right syntax.

@melissa I've included the facter output from AMZ 1 and AMZ 2 in my first comment.
I'd love to add a new, more specific default instead of lumping Amazon together with RedHat. I'm just not sure how. I'm also stuck on writing these spec tests. They're not very similar to the systemd spec tests when it comes to syntax, so I'm not sure how to get started on that.
If someone wants to walk me through it, I'd be happy to update this PR, otherwise, I'm open to having someone else take over this PR 😄

Oh, another point, if we're moving this to it's own line, then we don't have to have an os version constraint.
defaultfor :operatingsystem => :amazon

Are you looking at add tests to spec/unit/provider/package/yum_spec.rb? I'm happy to help with that! What do you have so far?

Oh, another point, if we're moving this to it's own line, then we don't have to have an os version constraint.
defaultfor :operatingsystem => :amazon

Good point, I added a new commit for that. Not sure if it's correct though.

Are you looking at add tests to spec/unit/provider/package/yum_spec.rb? I'm happy to help with that! What do you have so far?

Yes, I think thats where the spec tests for this need to go.
I've done nothing so far besides compare yum_spec.rb to systemd_spec.rb and I'm confused 😄

In your update, you're using the example I originally gave: :osname, but I think we should use the same check they're using in systemd, which is going to be defaultfor :operatingsystem => :amazon. The tests below assume you've changed osname to operatingsystem. I have no idea which is preferable :(
I'm not sure if you only wanted a hint, but here's what I would add. Feel free to copy/modify/change/update/reword/etc as you see fit.
diff --git a/spec/unit/provider/package/yum_spec.rb b/spec/unit/provider/package/yum_spec.rb
index 53f3969c0f..59a5c18079 100644
--- a/spec/unit/provider/package/yum_spec.rb
+++ b/spec/unit/provider/package/yum_spec.rb
@@ -12,6 +12,40 @@ describe Puppet::Type.type(:package).provider(:yum) do
     expect(described_class.specificity).to be < 200
   end

+  describe "should have logical defaults" do
+    [2,2018].each do |ver|
+      it "should be the default provider on Amazon Linux #{ver}" do
+        allow(Facter).to receive(:value).with(:operatingsystem).and_return('amazon')
+        allow(Facter).to receive(:value).with(:osfamily).and_return('redhat')
+        allow(Facter).to receive(:value).with(:operatingsystemmajrelease).and_return('2018')
+        expect(described_class).to be_default
+      end
+    end
+
+    Array(4..7).each do |ver|
+      it "should not be default for redhat #{ver}" do
+        allow(Facter).to receive(:value).with(:operatingsystem).and_return('redhat')
+        allow(Facter).to receive(:value).with(:osfamily).and_return('redhat')
+        allow(Facter).to receive(:value).with(:operatingsystemmajrelease).and_return(ver.to_s)
+        expect(described_class).to be_default
+      end
+    end
+
+    it "should not be default for redhat 8" do
+      allow(Facter).to receive(:value).with(:operatingsystem).and_return('redhat')
+      allow(Facter).to receive(:value).with(:osfamily).and_return('redhat')
+      allow(Facter).to receive(:value).with(:operatingsystemmajrelease).and_return('8')
+      expect(described_class).not_to be_default
+    end
+
+    it "should not be default for Ubuntu 16.04" do
+      allow(Facter).to receive(:value).with(:operatingsystem).and_return('ubuntu')
+      allow(Facter).to receive(:value).with(:osfamily).and_return('ubuntu')
+      allow(Facter).to receive(:value).with(:operatingsystemmajrelease).and_return('16.04')
+      expect(described_class).not_to be_default
+    end
+  end

These tests, without your change, give me
$ bundle exec rspec --seed 123 --format documentation spec/unit/provider/package/yum_spec.rb:15
Run options:
  include {:locations=>{"./spec/unit/provider/package/yum_spec.rb"=>[15]}}
  exclude {:broken=>true, :benchmark=>true}

Randomized with seed 123

Puppet::Type::Package::ProviderYum
  should have logical defaults
    should not be default for redhat 4
    should not be default for redhat 8
    should be the default provider on Amazon Linux 2018 (FAILED - 1)
    should not be default for redhat 7
    should not be default for Ubuntu 16.04
    should be the default provider on Amazon Linux 2 (FAILED - 2)
    should not be default for redhat 5
    should not be default for redhat 6

Failures:

  1) Puppet::Type::Package::ProviderYum should have logical defaults should be the default provider on Amazon Linux 2018
     Failure/Error: expect(described_class).to be_default
       expected `Puppet::Type::Package::ProviderYum.default?` to return true, got false
     # ./spec/unit/provider/package/yum_spec.rb:21:in `block (4 levels) in <top (required)>'

  2) Puppet::Type::Package::ProviderYum should have logical defaults should be the default provider on Amazon Linux 2
     Failure/Error: expect(described_class).to be_default
       expected `Puppet::Type::Package::ProviderYum.default?` to return true, got false
     # ./spec/unit/provider/package/yum_spec.rb:21:in `block (4 levels) in <top (required)>'

Finished in 0.06879 seconds (files took 1.67 seconds to load)
8 examples, 2 failures

Failed examples:

rspec ./spec/unit/provider/package/yum_spec.rb[1:3:2] # Puppet::Type::Package::ProviderYum should have logical defaults should be the default provider on Am
azon Linux 2018
rspec ./spec/unit/provider/package/yum_spec.rb[1:3:1] # Puppet::Type::Package::ProviderYum should have logical defaults should be the default provider on Am
azon Linux 2

Randomized with seed 123

which is what we want!
with your change, it's
$ bundle exec rspec --seed 123 --format documentation spec/unit/provider/package/yum_spec.rb:15
Run options:
  include {:locations=>{"./spec/unit/provider/package/yum_spec.rb"=>[15]}}
  exclude {:broken=>true, :benchmark=>true}

Randomized with seed 123

Puppet::Type::Package::ProviderYum
  should have logical defaults
    should not be default for redhat 4
    should not be default for redhat 8
    should be the default provider on Amazon Linux 2018
    should not be default for redhat 7
    should not be default for Ubuntu 16.04
    should be the default provider on Amazon Linux 2
    should not be default for redhat 5
    should not be default for redhat 6

Finished in 0.06041 seconds (files took 1.63 seconds to load)
8 examples, 0 failures

Randomized with seed 123

Full set of changes:
$ git diff upstream/master
diff --git a/lib/puppet/provider/package/yum.rb b/lib/puppet/provider/package/yum.rb
index 1a00b88424..405184ba78 100644
--- a/lib/puppet/provider/package/yum.rb
+++ b/lib/puppet/provider/package/yum.rb
@@ -22,6 +22,7 @@ Puppet::Type.type(:package).provide :yum, :parent => :rpm, :source => :rpm do
       end
   end

+defaultfor :operatingsystem => :amazon
 defaultfor :osfamily => :redhat, :operatingsystemmajrelease => (4..7).to_a

   def self.prefetch(packages)
diff --git a/spec/unit/provider/package/yum_spec.rb b/spec/unit/provider/package/yum_spec.rb
index 53f3969c0f..59a5c18079 100644
--- a/spec/unit/provider/package/yum_spec.rb
+++ b/spec/unit/provider/package/yum_spec.rb
@@ -12,6 +12,40 @@ describe Puppet::Type.type(:package).provider(:yum) do
     expect(described_class.specificity).to be < 200
   end

+  describe "should have logical defaults" do
+    [2,2018].each do |ver|
+      it "should be the default provider on Amazon Linux #{ver}" do
+        allow(Facter).to receive(:value).with(:operatingsystem).and_return('amazon')
+        allow(Facter).to receive(:value).with(:osfamily).and_return('redhat')
+        allow(Facter).to receive(:value).with(:operatingsystemmajrelease).and_return('2018')
+        expect(described_class).to be_default
+      end
+    end
+
+    Array(4..7).each do |ver|
+      it "should not be default for redhat #{ver}" do
+        allow(Facter).to receive(:value).with(:operatingsystem).and_return('redhat')
+        allow(Facter).to receive(:value).with(:osfamily).and_return('redhat')
+        allow(Facter).to receive(:value).with(:operatingsystemmajrelease).and_return(ver.to_s)
+        expect(described_class).to be_default
+      end
+    end
+
+    it "should not be default for redhat 8" do
+      allow(Facter).to receive(:value).with(:operatingsystem).and_return('redhat')
+      allow(Facter).to receive(:value).with(:osfamily).and_return('redhat')
+      allow(Facter).to receive(:value).with(:operatingsystemmajrelease).and_return('8')
+      expect(described_class).not_to be_default
+    end
+
+    it "should not be default for Ubuntu 16.04" do
+      allow(Facter).to receive(:value).with(:operatingsystem).and_return('ubuntu')
+      allow(Facter).to receive(:value).with(:osfamily).and_return('ubuntu')
+      allow(Facter).to receive(:value).with(:operatingsystemmajrelease).and_return('16.04')
+      expect(described_class).not_to be_default
+    end
+  end
+
   describe "when supplied the source param" do
     let(:name) { 'baz' }

Nice job squashing the commits!
Would you also be willing to add the facter output to the commit message? It'll help folks in the future when messing with amazon things.

Actually, we should update the commit message to be a bit more descriptive before we merge this in.
In this commit message, we don't really care that Amazon Linux reports majrelease as 2018, we care that Amazon Linux has a default package manager and that default is yum.
Something along the lines of
(maint) Default Amazon Linux to yum

Prior to this commit, Amazon Linux did not have a default package provider set. This commit ensures that all versions of Amazon Linux will default to using the yum package provider.

Users will no longer get a warning about multiple default package providers.

We should update the commit message to be a bit more descriptive before we merge this in.
In this commit message, we don't really care that Amazon Linux reports majrelease as 2018, we care that Amazon Linux has a default package manager and that default is yum.
Something along the lines of
(maint) Default Amazon Linux to yum

Prior to this commit, Amazon Linux did not have a default package provider set. This commit ensures that all versions of Amazon Linux will default to using the yum package provider.

Users will no longer get a warning about multiple default package providers.

Done and done. Thanks for all the help!

👍 Probably want to squash the two commits in this PR into a single one.  As-is, the second commit's message will fail the commit message checker in the travis tests, and since it's fixing the title of a brand new test, it may as well be added with the fixed title in the first place. 😄

👍 Probably want to squash the two commits in this PR into a single one. As-is, the second commit's message will fail the commit message checker in the travis tests, and since it's fixing the title of a brand new test, it may as well be added with the fixed title in the first place. 😄

Squashed.

@cabrinha Thanks for all your work on this!


explain the (1) "golden diff" (2) golden comparator feature in readme and blog

readme

[ ] "golden diff"
[ ] golden comparator feature

blog

[ ] "golden diff"
[ ] golden comparator feature

bump


Stuck during multi-machine multi-GPU training

Stuck during multi-machine multi-GPU training
initializing distributed: GLOBAL_RANK: 0, MEMBER: 1/16
Can you help analyze what might be the reason?Thank @lllyasviel

Hi, did you solve the multi gpu training problem? I can train on several GPU but the synthesis image doesn't follow the condition. But it works if I set the gpu number to be 1 with similar training epochs. Have you met this before?

Very weird.. sadly my problem persists.

Hi, did you solve the multi gpu training problem? I can train on several GPU but the synthesis image doesn't follow the condition. But it works if I set the gpu number to be 1 with similar training epochs. Have you met this before?

Same here, the tutorial_train.py is working with batch size =1 & GPU=1, but not during multi GPU setting .
curious about the training time of your experiment; how many epochs and how much time it took per epoch.

HuggingFace Diffusers ControlNet training script https://huggingface.co/docs/diffusers/training/controlnet has different performance optimizations builtin

all duplicates concerning "Multi GPU"
https://github.com/lllyasviel/ControlNet/issues/148
https://github.com/lllyasviel/ControlNet/issues/314
https://github.com/lllyasviel/ControlNet/issues/319
https://github.com/lllyasviel/ControlNet/issues/507


Add support for CircleCI

Add CI configuration
Add various things to .gitignore
Add build badge to README

gonna do it because we need CI


Fixed value mapping for HH3C

Based on official HPE MIB files and also some public references, like http://www.circitor.fr/Mibs/Html/H/HH3C-ENTITY-EXT-MIB.php#hh3cEntityExtErrorStatus the value mapping should be as proposed.

Thanks for your contribution!


MongoCK ChangeUnit doesn't auto wire other spring beans as dependency

Description
How do I make the ChangeUnit work with other spring beans in my app, ChangeUnits doesn't seem to be importing the dependencies before running the execution annotated method.
PRIORITY
[CRITICAL]
Version and environment
Mongock

Mongock version - 5.3.4
Modules involved(springboot, reactive-driver)
How Mongock is used(builder or annotation approach, etc.) builder approach.

Environment

Framework and libraries versions. Especially those that affect directly to Mongock(Spring, Spring data, MongoDB driver, etc.) - Spring Boot version 2.7.1, Mongo 4.4, MongoDB-driver-reactivestreams 4.6.1, spring-data-mongodb 3.4.14

Steps to Reproduce
I've tried adding dependencies to the ChangeUnit via construction injection and setter injection, and using post construct to build the data I want to seed. But I get a
Caused by: java.lang.IllegalArgumentException: documents can not be null
exception while running the change unit, at line
mongoDatabase.getCollection("form_layouts", FormLayout.class)
    .insertMany(clientSession, formLayouts)
    .subscribe(insertSubscriber);

here's the code
private List<FormLayout> formLayouts;

@Autowired
private Jackson2ObjectMapperBuilder objectMapperBuilder;

@Autowired
private AppProperties appProperties;

@Value("classpath:form_layouts.json")
private Resource layouts;

@PostConstruct
public void initializeLayoutsJson() throws IOException {
    ObjectMapper objectMapper = objectMapperBuilder.failOnUnknownProperties(Boolean.TRUE).build();
    this.formLayouts = objectMapper.readValue(Files.readString(Path.of(layouts.getFile().getAbsolutePath())), new TypeReference<>() {
    });
    for (FormLayout layout : formLayouts) {
        layout.setRealmId(appProperties.getRealmId());
    }
    log.debug("Loaded {} Layouts from file seeder JSON {}", formLayouts.size(), layouts.getFilename());
    int i = 0;
    for (FormLayout layout : formLayouts) {
        i++;
        log.debug("Layout-{} : {}", i, layout);
    }
}

@Execution
public void migrationMethod(ClientSession clientSession, MongoDatabase mongoDatabase) {
    final SubscriberSync<InsertManyResult> insertSubscriber = new MongoSubscriberSync<>();
    mongoDatabase.getCollection("form_layouts", FormLayout.class)
            .insertMany(clientSession, this.formLayouts)
            .subscribe(insertSubscriber);
    InsertManyResult result = insertSubscriber.getFirst();
    log.info("{}.execution() wasAcknowledged: {}", this.getClass().getSimpleName(), result.wasAcknowledged());
    result.getInsertedIds()
            .forEach((key, value) -> log.info("Added Object[{}] : {}", key, value));
}

I've also tried constructor injection
private final List<FormLayout> formLayouts;

public LayoutsDataInitializer(@Autowired Jackson2ObjectMapperBuilder objectMapperBuilder, @Autowired AppProperties appProperties,
                              @Value("classpath:form_layouts.json") Resource layouts) throws IOException {
    ObjectMapper objectMapper = objectMapperBuilder.failOnUnknownProperties(Boolean.TRUE).build();
    this.formLayouts = objectMapper.readValue(Files.readString(Path.of(layouts.getFile().getAbsolutePath())), new TypeReference<>() {
    });
    for (FormLayout layout : formLayouts) {
        layout.setRealmId(appProperties.getRealmId());
    }
}

@Execution
public void migrationMethod(ClientSession clientSession, MongoDatabase mongoDatabase) throws IOException {
    final SubscriberSync<InsertManyResult> insertSubscriber = new MongoSubscriberSync<>();
    mongoDatabase.getCollection("form_layouts", FormLayout.class)
            .insertMany(clientSession, formLayouts)
            .subscribe(insertSubscriber);
    InsertManyResult result = insertSubscriber.getFirst();
    log.info("{}.execution() wasAcknowledged: {}", this.getClass().getSimpleName(), result.wasAcknowledged());
    result.getInsertedIds()
            .forEach((key, value) -> log.info("Added Object[{}] : {}", key, value));
}

This gives a rather cryptic error about wrong Dependency Caused by: io.mongock.driver.api.common.DependencyInjectionException: Wrong parameter[Resource]. Dependency not found.
in ChangeLogRuntimeImpl. Moving the entire logic into execution method also does not help.
@Value("classpath:form_layouts.json")
Resource layouts;

@Execution
public void migrationMethod(ClientSession clientSession, MongoDatabase mongoDatabase) throws IOException {
    ObjectMapper objectMapper = new ObjectMapper();
    objectMapper.configure(DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, Boolean.TRUE);
    List<FormLayout> formLayouts = objectMapper.readValue(Files.readString(Path.of(layouts.getFile().getAbsolutePath())), new TypeReference<>() {
    });
    for (FormLayout layout : formLayouts) {
        layout.setRealmId(REALM_ID);
    }
    final SubscriberSync<InsertManyResult> insertSubscriber = new MongoSubscriberSync<>();
    mongoDatabase.getCollection("form_layouts", FormLayout.class)
            .insertMany(clientSession, formLayouts)
            .subscribe(insertSubscriber);
    InsertManyResult result = insertSubscriber.getFirst();
    log.info("{}.execution() wasAcknowledged: {}", this.getClass().getSimpleName(), result.wasAcknowledged());
    result.getInsertedIds()
            .forEach((key, value) -> log.info("Added Object[{}] : {}", key, value));
}

Fails as the layouts object is reported Null.
Behaviour
Expected behavior:
ChangeUnit to be applied successfully.
Actual behavior:
Application startup fails due to errors mentioned in the steps to reproduce section.
How often the bug happens:
100%

Hello @anadimisra , your question is answered in stackoverflow. Please take a look and it's useful, mark the answer as useful, that will help us a lot.
Thanks

Thanks @dieppa ! I'll detail my findings here

It works if the fields autowired in the constructor are also private final in the bean and I set them. Now there can be a case where I'm autowiring constructor dependencies for initialising other private fields of this object and I don't need the autowired beans outside of the constructor - in such cases I get the wrong Parameter error which I should not
While other setter injection based and method parameter based dependency injection works, @Value annotated parameters don't get autowired definitely. Like in my case it was @Value("classpath:form_templates") Resource templateFile


Investigate playwritght Signed Headers against the Status and Report

Changes were done to test webapp without interacting with the extension. PR - https://github.com/GLEIF-IT/reg-pilot-webapp/pull/87/files


Invalid pointer in C++

Hello,
I got some invalid pointer error when I was trying to run the cpp tests. (They are compiled via "make test"). Does anyone has the same problem? Or if it is a expected behavior?
I got errors in both storage_test and threaded_engine_test, and I tried to compile mxnet using both atlas and openblas with no luck...
Running main() from gtest_main.cc
[==========] Running 2 tests from 1 test case.
[----------] Global test environment set-up.
[----------] 2 tests from Engine
[ RUN      ] Engine.RandSumExpr
[00:47:30] tests/cpp/threaded_engine_test.cc:122: data: 6.51017e-06 7.82748e-06...
[00:47:32] tests/cpp/threaded_engine_test.cc:122: data: 1.18768e-05 1.21442e-05...
[00:47:34] tests/cpp/threaded_engine_test.cc:122: data: 7.94116e-06 7.92518e-06...
[00:47:36] tests/cpp/threaded_engine_test.cc:122: data: 5.96905e-06 5.86879e-06...
[00:47:38] tests/cpp/threaded_engine_test.cc:122: data: 7.40273e-06 8.94093e-06...
[00:47:38] tests/cpp/threaded_engine_test.cc:126: baseline		2.88566 sec
[00:47:38] tests/cpp/threaded_engine_test.cc:127: NaiveEngine		2.90509 sec
[00:47:38] tests/cpp/threaded_engine_test.cc:128: ThreadedEnginePooled	0.891581 sec
[00:47:38] tests/cpp/threaded_engine_test.cc:129: ThreadedEnginePerDevice	2.94941 sec
[       OK ] Engine.RandSumExpr (9662 ms)
[ RUN      ] Engine.basics
============= Test #1 ==============
The fox says 0
The fox says 1
The fox says 2
The fox says 3
The fox says 4
The fox says 5
The fox says 6
The fox says 7
The fox says 8
The fox says 9
Going to push delete
============= Test #2 ==============
The fox says 0
The fox says 1
The fox says 2
The fox says 3
The fox says 4
The fox says 5
The fox says 6
The fox says 7
The fox says 8
The fox says 9
============= Test #3 ==============
============= Test #4 ==============
[00:47:53] tests/cpp/threaded_engine_test.cc:198: IO operator pushed, should wait for 2 seconds.
The fox says 42
[00:47:55] tests/cpp/threaded_engine_test.cc:200: OK, here I am.
============= Test #5 ==============
[00:47:55] tests/cpp/threaded_engine_test.cc:218: Operator pushed, should not wait.
[00:47:55] tests/cpp/threaded_engine_test.cc:220: OK, here I am.The fox says 42

[00:47:57] tests/cpp/threaded_engine_test.cc:222: That was 2 seconds.
[00:47:57] tests/cpp/threaded_engine_test.cc:230: All pass
[       OK ] Engine.basics (19003 ms)
[----------] 2 tests from Engine (28666 ms total)

[----------] Global test environment tear-down
[==========] 2 tests from 1 test case ran. (28666 ms total)
[  PASSED  ] 2 tests.
*** Error in `./tests/cpp/threaded_engine_test': free(): invalid pointer: 0x0000000001dd9ca0 ***
======= Backtrace: =========
/usr/lib/libc.so.6(+0x72055)[0x7ff1c73e7055]
/usr/lib/libc.so.6(+0x779a6)[0x7ff1c73ec9a6]
/usr/lib/libc.so.6(+0x7818e)[0x7ff1c73ed18e]
/usr/lib/libc.so.6(__cxa_finalize+0x8f)[0x7ff1c73ab2ef]
/usr/lib/libgtest.so(+0x185f3)[0x7ff1c80ed5f3]
======= Memory map: ========
00400000-00487000 r-xp 00000000 08:09 21759679                           /home/thyu/work/mxnet/tests/cpp/threaded_engine_test
00686000-00688000 rw-p 00086000 08:09 21759679                           /home/thyu/work/mxnet/tests/cpp/threaded_engine_test
01cea000-0262c000 rw-p 00000000 00:00 0                                  [heap]
7ff158000000-7ff158021000 rw-p 00000000 00:00 0
7ff158021000-7ff15c000000 ---p 00000000 00:00 0

is this an reproducible test on your side? This is likely due to problem during destruction, which should not pose a problem for normal training, but would be nice if you can use gdb to look into what is going on.
Thanks


[BUG] v8.0.0  don't have any .tar.xz  release for Debian.

in the new update v8.0.0 i don't see any .tar.xz  release for Debian.

Hey @Erreur32 I've updated the release and the tar.xz for Debian is now available.

Heads up I will need to rename these for the next release to distinguish between x86, arm and arm64 builds. Likely the file will just have the arch in the name.

This did break the arch user repository package, as it noticed the files have changed since the initial release:
==> Making package: go-hass-agent-bin 8.0.0-1 (Mon 29 Apr 2024 01:11:17 PM CEST)
==> Checking runtime dependencies...
==> Checking buildtime dependencies...
==> Retrieving sources...
  -> Found go-hass-agent-8.0.0.pkg.tar.zst
==> Validating source files with sha256sums...
    go-hass-agent-8.0.0.pkg.tar.zst ... FAILED
==> ERROR: One or more files did not pass the validity check!
 -> error making: go-hass-agent-bin-exit status 1
 -> Failed to install the following packages. Manual intervention is required:

https://aur.archlinux.org/cgit/aur.git/tree/PKGBUILD?h=go-hass-agent-bin

Oh wow, I didn't know someone had packaged it up in AUR. Neat! Though I'm not familiar with packaging for arch (I'm using a tool, nfpm, which handles it for me).
If there is something I can do to make it easier to package, please let me know!

This should be fixed now for future releases, there was a single character breaking the build pipeline.


Helm v3 beta -- Wait for CRDs to be created

When deploying CRDs with Helm v3, the rest of the chart deployment occurs immediately after a CRD is installed.  This can cause the chart deployment to fail if the CRDs are not yet available.  Helm should wait until the CRD is deployed before continuing with the chart.

@mattfarina @technosophos What do you think?

So the problem isn't actually the amount of time that passes. It's that the local cache (~/.kube/...) is not updated. We need to find a way to invalidate that cache, and then things should work. I believe @thomastaylor312 has looked into this as well.

Fixed in #6332


[0.5.x] Fail running HMR in known environments

This PR introduces some nice errors for developers when running the HMR server (npm run dev) in known environments where it shouldn't be run, specifically:

Vapor
Forge
Misc Continuous Integration

It does not yet support Envoyer, as I'm not aware of an ENV value to be able to check, but I would like to add support if it makes sense.
The ENV check can be overridden:
LARAVEL_BYPASS_ENV_CHECK=1 npm run dev

Tested:

[x] Forge (awaiting PR merge)
[ ] Vapor (awaiting ENV name)
[x] CI: I haven't tested this as the plugin hasn't been released, but I put together a quick test to ensure that NPM will see the var is defined. Result: https://github.com/timacdonald/test/runs/8010051201?check_suite_focus=true

Actually I take it back. I dog-fooded the CI check with this plugin: https://github.com/laravel/vite-plugin/runs/8009908254?check_suite_focus=true

Forge output when running npm run dev in the deploy script (although we have updated the error wording since).

Converted to draft until we have the Envoyer var merged.

Small nitpick: rephrase "Vite HMR server" to "Vite development server", as said server is not only for HMR - in fact, sometimes HMR is not even available


[Android] RadioButtonInput with large borderWidth has an X in it

BUG - Android does not render large borders correctly
How to Reproduce
My implementation of RadioButtonInput looks like this:
<RadioButtonInput
  obj={obj}
  index={index}
  onPress={() => onPress(index)}
  borderWidth={obj.selected ? 10 : 2}
  buttonOuterColor={obj.selected ? '#702779' : '#BDBDBD'}
  buttonOuterSize={30}
  buttonSize={0}
/>

Expected Behavior
On iOS it (correctly) looks like this:

Actual Behavior
On Android it (incorrectly) looks like this:

Here's a blown up view of the button on Android:

As you can see, the iOS button displays without issue but the Android button shows a small grey "X" in it.
Conclusion
Please advise as to a possible solution or comment if you have had this issue before.

Hey everyone! I found a workaround by using the buttonStyle props and utilizing the two circles.
Here's my workaround.
<RadioButtonInput
  obj={obj}
  index={index}
  onPress={() => onPress(index)}
  isSelected={obj.selected}
  borderWidth={obj.selected ? 1 : 2}
  buttonOuterColor={obj.selected ? '#702779' : '#BDBDBD'}
  buttonOuterSize={30}
  buttonInnerColor={'#FFFFFF'}
  buttonSize={10}
  buttonStyle={obj.selected
    ? StyleSheet.flatten({backgroundColor: '#702779'})
    : StyleSheet.flatten({backgroundColor: '#FFFFFF'})
  }
/>

It works like a charm since it gets around the circle border issue of react-native.
I'm going to close this issue since it's been resolved.


Add Trace browser addon

Trace

Trace - protects the user against common browser fingerprinting methods.
Why do you think this helps users privacy?: randomizes and hides some information that can be used for browser fingerprinting.
Under what section should this service be listed?: browser addons

This project seems unmaintained for over a year now


ENH: Change package name from qrisk to empyrical

The repository formerly known as qrisk is now named empyrical. The name had to be changed in many files.

lgtm

although i still prefer pyrachute 😢


accounts to 0.0.1

Promote accounts to version 0.0.1

[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
To fully approve this pull request, please assign additional approvers.
We suggest the following additional approvers:
If they are not already assigned, you can assign the PR to them by writing /assign  in a comment when ready.
The full list of commands accepted by this bot can be found here.
The pull request process is described here

Needs approval from an approver in each of these files:

OWNERS

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

@tokeskovgaard: The following test failed, say /retest to rerun them all:

Test name
Commit
Details
Rerun command

promotion-build
e5d036390b43d5cb7f6c03e5d99c38148484e4df
link
/test this

Instructions for interacting with me using PR comments are available here.  If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.


Is there is a chance of upgrading to Bootstrap v5?

I like Flask-User a lot it is amazing and saves me a lot of boilerplates.
You have done a really great job here 👏.
Nowadays when I create a project I use latest Bootstrap currently v5 and Flask-User uses Bootstrap v3.
So I am forced to downgrade the project bootstrap version to v3 to avoid any conflicts.
Any other solution I find in my little head 🐵 right now will bring another set of boilerplates 😅.
So is there is a chance to upgrade to latest version or pointing me to a better idea.
Thanks again for everything 😊.

I have a fork that consists of version upgrades and small fixes. https://github.com/lohjine/Flask-User-starter-app/tree/master

Thanks mate 😊I'll definitely check it out 😉
Kind regards,
Mohamed Gamal
On Thu, 10 Nov 2022 at 2:18, @.***> wrote:
I have a fork that consists of version upgrades and small fixes. https://github.com/lohjine/Flask-User-starter-app/tree/master
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you authored the thread.Message ID: @.***>


Set evaluates as a map when using execute-top-block

If I execute #{1 |2 4} using ctrl-, B (where| shows the cursor location) then I get the following error: RuntimeException Map literal must contain an even number of forms...
If I select the whole set form (including the hash) and evaluate using ctrl-, s then the set evaluates as expected.

When I execute #{1 2 3} using alt-cmd-B on Mac I get a map exception message. Cursor position doesn't matter for me:
RuntimeException Map literal must contain an even number of forms  clojure.lang.Util.runtimeException (Util.java:221)


Reviewable by commit.

test-me-please

Coverage decreased (-0.001%) to 37.006% when pulling a1cd0b899a7f135d570402375e14104a3505a461 on pr/tklauser/drop-pkg-errors into 192455653ada5acb32590994660ad90603651c69 on master.


Dropping "NativeTypes.FILE" stopped working in Chrome 47

I've prepared a minimal example here: https://github.com/danielberndt/react-starter/tree/react-dnd-test
When dropping an image, it should be calling the drop method but instead the file gets opened in the browser. No warning or error gets issued.
This fails on Chrome 47 on Mac 10.9.5. It works fine on Firefox and used to work fine on earlier versions of Chrome on my machine.

I did some digging in the code, and it turns out that the 'mousemove' event registered here fires too early on Chrome. This is why a DRAG_END is fired before the drop handler is processed, causing the issue.

Okay, I've just have seen #4. It's fix is probably cause for this issue here.

I can confirm. Chrome 47 doesn't seem to be responding to file drop events (even hover). Works fine in Firefox though though.

current workaround is to use the 2.0.0 version.

Is this still an issue with Chrome 48?

This should be fixed in<EMAIL_ADDRESS>


feat: support formatting Cargo.toml

From the disscussion in https://github.com/rust-lang/rustfmt/issues/4091, rustfmt should support format Cargo.toml since the Style Guide actually already includes a spec for Cargo.toml.
And things to consider include:

formatting logic
experience/usability perspective: (default behavior, cli args/opts, configurable via rustfmt.toml, etc)

As such I'd advise starting with the formatting logic (something that takes in an unformatted string and returns a formatted one) and we'll figure out the rest later on. Feel free to put this in a new mod under src/formatting

Originally posted by @calebcartwright in https://github.com/rust-lang/rustfmt/issues/4091#issuecomment-730716157

I do not think deferring the actual formatting logic to an external library is likely to be a viable candidate for the reasons that I've outlined above. We've got a formatting spec we'd have to follow, and even if one or more versions of said external lib happen to emit the same formatting, there's no guarantee they'd continue to do so (and we couldn't use a pinned version either due to risk of update blockage)

Originally posted by @calebcartwright in https://github.com/rust-lang/rustfmt/issues/4091#issuecomment-914846250
So in this PR I implemented the formatting logic according to the style guide. I used https://github.com/ordian/toml_edit to do so in an extensible way (visitors).

Haven't looked at the diff yet but very excited to see this, thanks so much for getting the process started @xxchan!

@calebcartwright @ytmimi Would you have some time recently to review this PR and give some feedbacks? At least for the general idea and code structure of the PR. 😊

Thank you for your patience @xxchan. I'm currently in the closing steps of prepping the next release, and afterwards I'll circle back to this and some of the larger/older PRs that have been pending

I also want to acknowledge that I've seen this and say that I'll try to carve out some time next week to start a review

@ytmimi Thanks for your review! I will resolve comments later.
For the calling path and tests, do we plan to keep working on this PR or get it merged first?

For the calling path and tests, do we plan to keep working on this PR or get it merged first?

I think I'd be fine either way, but it would definitely be ideal (at least in my opinion) if we could keep iterating on this PR before merging. I'll also wait for @calebcartwright to chime in before we decide how we'll move forward.

For the calling path and tests, do we plan to keep working on this PR or get it merged first?

I think I'd be fine either way, but it would definitely be ideal (at least in my opinion) if we could keep iterating on this PR before merging. I'll also wait for @calebcartwright to chime in before we decide how we'll move forward.

Not sure if this answers any specifics, but generally speaking we can certainly batch the overall implementation across multiple PRs (smaller PRs are always better in my mind). However, let's also make sure that each chunk/PR is complete. We can certainly update signatures, move items around between files/mods, etc. but we should have whatever we add here fully tested and with the api we think makes sense at this point.

Hey @xxchan Thanks again for your work on getting this started. I know you mentioned that you were a little busy https://github.com/rust-lang/rustfmt/issues/4091#issuecomment-1083603647, so I went ahead and rebased your changes on the current master and add the additions to get format_cargo_toml on a path that will be called by rustfmt.
I probably want to add a few more tests, but I think we're in a good place implementation wise.

Excellent can't wait for this to land so that we can stop manually worrying about how Cargo.toml should be formatted. This is the improvement in rust I am most looking forward to this year!

Excellent can't wait for this to land so that we can stop manually worrying about how Cargo.toml should be formatted. This is the improvement in rust I am most looking forward to this year!

Just to be clear, this PR doesn't fully implement the feature in and of itself, just an important first step

I’ll take a first step!
On Sun, 8 May 2022 at 19:23, Caleb Cartwright @.***>
wrote:

Excellent can't wait for this to land so that we can stop manually
worrying about how Cargo.toml should be formatted. This is the improvement
in rust I am most looking forward to this year!
Just to be clear, this PR doesn't fully implement the feature in and of
itself, just an important first step
—
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rustfmt/pull/5240#issuecomment-1120465190,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGEJCD5QRRVPUC6HQ7QQBLVJABDPANCNFSM5PLIHPZA
.
You are receiving this because you commented.Message ID:
@.***>

Anyone here can suggest more test cases like https://github.com/rust-lang/rustfmt/pull/5240/files#diff-3ab626d68c49333207c9209bf5abb01c7b2eff301470bd5dcc801da3dcf2345f? 😄

I've added a new rule TrimSpaces, it's not described in style guide, but maybe it's expected

Hi @ytmimi @calebcartwright, I added an unstable option format_cargo_toml and integrated the support for Cargo.toml to cargo-fmt, so I think this PR is now ready to be merged and let users to play with it. 😊

Thanks for your review!

I'm not sure if we're ready to add this to cargo fmt.

I believe most of users use cargo fmt instead of using rustfmt directly, and they expect cargo fmt to handle the whole workspace. So I think adding it to cargo fmt is a critical step for this long-awaited feature to have enough exposure and user testing. It's also the reason why I think this PR is good enough to be merged instead of being blocked for too long.
I will resolve other comments soon.

Comments expect those about cargo-fmt resolved.

Would love to use this feature! Is there something that we're waiting on?

Great timing - this is top of my xmas list.
On Wed, 14 Dec 2022 at 08:29, xxchan @.***> wrote:

IMO it's good enough to merge. cc @ytmimi https://github.com/ytmimi
Could you confirm that and update the PR label?
—
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rustfmt/pull/5240#issuecomment-1350625107,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGEJCATKIHOQELAQ7YG4VTWNGAOPANCNFSM5PLIHPZA
.
You are receiving this because you commented.Message ID:
@.***>

Please take some time on this. We really need this!

Adding to the positive sentiment. This would be really useful for my team and me if this is merged soon! :)

As soon as it’s in nightly then people can give lots of feedback - even if
it’s behind a flag and not default for now.
On Mon, 6 Feb 2023 at 20:17, Andrew Gazelka @.***>
wrote:

Adding to the positive sentiment. This would be really useful for my team
and me if this is merged soon! :)
—
Reply to this email directly, view it on GitHub
https://github.com/rust-lang/rustfmt/pull/5240#issuecomment-1419693155,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAGEJCAETUYSSAORYG7LY6LWWFL6BANCNFSM5PLIHPZA
.
You are receiving this because you commented.Message ID:
@.***>

Are we going to merge this?? We are waiting for it.

Adding to the chorus here: is there something holding this back?

I'd kindly request that folks only comment here if they have feedback salient to the specifics of the proposed implementation. I understand the desire for the feature, but the repeated flavors of "+1" comments don't impact the priority+work vs. bandwidth challenges that we (and frankly most dev tools teams) have, and as such aren't going to result in anything happening more quickly.
These comments also make things a bit more challenging by extending the length of the thread and unnecessarily notifying those that have subscribed in order to be made aware of any substantial updates/movement.

If you want to try this on your project:
git clone https://github.com/rust-lang/rustfmt && cd rustfmt
gh pr checkout 5240
cargo build --release --bin rustfmt --bin cargo-fmt -Zunstable-options --out-dir "$(rustc --print=sysroot)/bin"

This installation is safe and won't pollute other installations.
Then you will be able to use it as cargo +nightly-2023-01-24 fmt on any project. Note you will also need to add format_cargo_toml = true in rustfmt.toml.

I have made a draft PR to a PR to try to resolve the current merge conflict - https://github.com/xxchan/rustfmt/pull/1 but it seems the recent changes in toml_edit by @epage to expose all underlying strings as RawString instead of simple &str made this PR much more difficult.
@xxchan, are you still working on this?  This code was pretty much ready to go until it wasn't, so hoping to resume the work on it :)

@nyurik Thanks for your work! But it seems your merge commit changed Cargo.lock too much, and thus I've manually merged main just now.
If you'd like to create a separate PR to bump toml_edit, I would happily merge it!

@xxchan, are you still working on this? This code was pretty much ready to go until it wasn't, so hoping to resume the work on it :)

I'm not working on it, and not very interested in pushing forward it (although there aren't any blockers AFAIK). But I'm happy to help if anyone wants to improve it (e.g., more tests, bugfix, etc).

@xxchan i would be happy to help with that PR - do you want to maybe add me to your fork?  This way i can push changes directly to your PR (again - only if you do want me to drive that PR forward)?

@nyurik Instead of pushing directly to this PR, it might be better if you either create PRs to be merged into this branch, or create another PR to master directly to replace this PR if you want to make significant changes :)

Thanks @xxchan, I pushed a new PR to upgrade toml_edit crate to the latest version in https://github.com/xxchan/rustfmt/pull/2

🎅 It's top of my Christmas list that with some flag set, nightly can format Cargo.toml files. I've been a really good boy all year.

While this has admittedly not been a priority for us on the Rustfmt team anyway, I also want to make sure that those interested in this feature are aware that the Cargo team have some concerns about the existing Style Guide prescriptions for the toml file and that there's still discussion to be had between the Cargo and Style teams about what the formatting rules should be.

If that's the case, perhaps it would be okay to put this under an unstable option (for example, cargo_toml = true) so that the existing code can be merged without stabilising the formatting? Assuming that the consensus is that it's okay for this code to live in rustfmt, just, not certain what it should do.

I second that if we are simply uncertain of the formatting details, but certain that we need it (as seems to be the consensus), I do think it should be merged under the nightly flag, same as --config imports_granularity=Module.  Options for the name:

include_toml
format_toml
toml
...?

If that's the case, perhaps it would be okay to put this under an unstable option

a config format_cargo_toml is already added https://github.com/rust-lang/rustfmt/pull/5240/files#diff-7bd4f14a75a37432af3ab896bbbe38f88428b490b5d76ed1586f7f473a745e98

the Cargo team have some concerns about the existing Style Guide prescriptions for the toml file and that there's still discussion to be had between the Cargo and Style teams about what the formatting rules should be.

Understand. I also feel some rules are not good enough, and some are missing. But I think

This implementation is extensible and very easy to change
With a working implementation for the current style guide, maybe it's easier to find what can be improved.

the Cargo team have some concerns about the existing Style Guide prescriptions for the toml file and that there's still discussion to be had between the Cargo and Style teams about what the formatting rules should be.

ref to https://github.com/rust-lang/style-team/issues/188

Just like formatting of rust code has changed over time, it's expected that formatting of Cargo.toml files would change over time (and double expected when the feature is only available in nightly). I have no doubt that releasing it to nightly will quickly lead to feedback around what the default formatting style should be. This is what nightly is for is it not?

To be clear, I'm trying to provide transparency about additional challenging external factors above and beyond the fact that this is an extremely low priority for a small, stretched team. I'm not trying to persuade anyone of anything, nor get dragged into a debate.

Just like formatting of rust code has changed over time

Fwiw, it hasn't. The Style Guide has been set in stone from the outset, as have the associated formatting rules. It wasn't until RFC 3338 (from 2022) that a process to change formatting even come into existence.

It's just not a particularly efficient use of our time to review code implementing formatting rules and that the associated test content based on those rules, for rules that are going to change.

To be clear, I'm trying to provide transparency about additional challenging external factors above and beyond the fact that this is an extremely low priority for a small, stretched team. I'm not trying to persuade anyone of anything, nor get dragged into a debate.

Totally understand, and glad that you can express this explicitly.

It's just not a particularly efficient use of our time to review code implementing formatting rules and that the associated test content based on those rules, for rules that are going to change.

FWIW, @ytmimi has spent time reviewing this several rounds, and thought we're on the right track.  This seems also not very efficient use of time.
Anyway, I'm not urgent at all to get this landed. But just want to say sth since we got updates from the maintainers' side. 😄

FWIW, @ytmimi has spent time reviewing this several rounds, and thought we're on the right track.  This seems also not very efficient use of time.

Understood. The Cargo team's objections are recent, and the prior rounds of review precede those objections.
This has admittedly been a lower priority from the outset, but it was something we were still trying to slowly advance. However, these new objections are now a blocker, and I'm simply communicating that blocker.

If this is about the parts of the style  that are undecided, how about we focus on the core infrastructure and easily agreed to items so this PR can be small and we can more easily iterate over time.  I also assume that the area where the cargo team pushed back are likely to be things people would want configurable so they can be added incrementally over time behind settings.

I'm really trying to avoid getting into broader discussion as well as the specifics of what/why/etc. because I think discussion on PRs should be largely centered review of the "how", the specifics of proposed implementation changes.
Ultimately, this is not something I'm comfortable moving ahead with, neither in whole nor in part, while we have other conversations circling elsewhere including moving some of the subcommands (like cargo-fmt) into Cargo and large unanswered questions around things like sorting.
I know people want this feature, I get it and I get why. For those that just want some/any type of formatting of their Cargo.toml files, several readily available options were previously shared on #4091.
However, this is something net-new and trying to force through for the sake of having something "now" from rustfmt is only going to introduce churn, both on users and on rustfmt itself, and we're not going to do it.
If that makes me the Grinch instead of Santa, then so be it :sweat_smile:

I'm really trying to avoid getting into broader discussion as well as the specifics of what/why/etc. because I think discussion on PRs should be largely centered review of the "how", the specifics of proposed implementation changes.

To be clear, I was trying to highlight what could be dropped to make this easier to move forward, from a cargo team member perspective, not to get into the broader discussion.

Ultimately, this is not something I'm comfortable moving ahead with at this time, neither in whole nor in part,

Please reconsider this.  Focusing on a more incremental approach should make your life much easier and gets people benefits now, rather than waiting for some future date.  We can pick less churn-heavy areas to move forward.

including moving some of the subcommands (like cargo-fmt) into Cargo and large unanswered questions around things like sorting.

I thought you said "no" to moving it?
As for sorting, if we leave that out, then it isn't a problem, right?

I'm going to redirect conversation about design/strategy/timing/etc. back to the issue and will respond there

However, this is something net-new and trying to force through for the sake of having something "now" from rustfmt is only going to introduce churn, both on users and on rustfmt itself, and we're not going to do it. When we do, it will be something we generally feel will be "right" and at least aligned with the anticipated path of the Style Rules.
If that makes me the Grinch instead of Santa, then so be it 😅

My particular concern here, speaking of someone who understands what it's like to contribute changes to large projects on my own time, is that it's incredibly frustrating to leave PRs in limbo like this. I'm fine with stripping out changes that could be changed/cause churn, I'm fine with deciding that you just don't want this change before design is done. What I'm not okay with is a change being open for almost two years in limbo.
It takes a lot of effort to rebase and review a change like this as it gets scrutinised, and it's especially frustrating to continue to have my change left open for months because it's in this weird limbo of not prioritised but not undesired.
The reason why I proposed merging under an unstable option is because it would mean this PR is closed and then additional work can happen in another PR.
Like, I understand the situation this puts you in as a maintainer, but I'm speaking from experience; either:

Merge it as-is
Provide criteria for what form it would need to be, to be merged
Close it

None of this "we don't know what the criteria is, don't want to work on it right now, but like some of what this is right now." That just makes everyone feel worse about it, both maintainers and contributors. IMHO, either decide if there's some portion of this you'd be comfortable merging now (and request those specific changes, likely involving removing pieces) or close this and tell people where they can follow the discussion in the meantime.

Does this produce Cargo.tomls like those cargo publish itself produces?

@glandium while there is work to define and enforce the style for Cargo.toml, I do not expect the cargo team will adjust cargo publish to make the Cargo.toml apply.  The file at that point is mostly for machine consumption.  This would be similar to cargo fix generating code that needs a cargo fmt run applied to it.

Any progress after all this time? What is stopping this work?

This would be very nice addition to the ecosystem!

This PR is blocked, as has been noted in multiple comments and with the label on this PR.
We, the rustfmt team are leaving the PR open because it's as good an implementation as any to pick up if and when the upstream blockers are removed. If the author wants to close the PR that's certainly their prerogative and an option they can take at any point.
I've locked the conversation on this PR because it's been attracting a number off-topic comments that do not offer any concrete feedback on the implementation nor remove the upstream blockers.
Those comments are adding noise and length to the PR which exacerbate the common open source issue of people commenting without reading prior comments, and it's also unnecessarily triggering notifications for those subscribed in order to receive substantive updates.


Create QuizzingGame.py

A simple quizzing game made using python and quiz api.

Please merge my pull request for this simple quizzing game made using api.

PR accepted @why-sid
Successfully merged to HacktoberFest_22 repo.
Need to Star this repo incase not done.
🚀🚀👍