Error: Cannot find module 'loady'

Hello,
I forked this repo and ran the default installation of Node.js with chocolatey on windows 10.
I tried both npm install and npm ci and after running node index.js both threw the error  Cannot find module 'loady'
__  __         _    _  _ ___ _____     ___              _
\ \/ /_ _ _ __| |  | \| | __|_   _|   / __|_ _ ___ __ _| |_ ___ _ _
 >  <| '_| '_ \ |  | .` | _|  | |    | (__| '_/ -_) _` |  _/ _ \ '_|
/_/\_\_| | .__/_|  |_|\_|_|   |_|     \___|_| \___\__,_|\__\___/_|
         |_|
2021-05-26 23:40:05 [info]:     starting IPFS node for content distribution
2021-05-26 23:40:07 [error]:    Cannot find module 'loady'
Require stack:
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\bcrypto\lib\native\binding.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\bcrypto\lib\native\hkdf.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\bcrypto\lib\hkdf.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\libp2p-noise\dist\src\utils.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\libp2p-noise\dist\src\handshakes\xx.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\libp2p-noise\dist\src\handshake-xx.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\libp2p-noise\dist\src\noise.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\libp2p-noise\dist\src\index.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\ipfs-core\src\runtime\libp2p-nodejs.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\ipfs-core\src\components\libp2p.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\ipfs-core\src\components\storage.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\ipfs-core\src\components\index.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\ipfs-core\src\index.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\index.js
2021-05-26 23:40:07 [error]:    StackTrace:
2021-05-26 23:40:07 [error]:    Error: Cannot find module 'loady'
Require stack:
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\bcrypto\lib\native\binding.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\bcrypto\lib\native\hkdf.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\bcrypto\lib\hkdf.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\libp2p-noise\dist\src\utils.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\libp2p-noise\dist\src\handshakes\xx.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\libp2p-noise\dist\src\handshake-xx.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\libp2p-noise\dist\src\noise.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\libp2p-noise\dist\src\index.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\ipfs-core\src\runtime\libp2p-nodejs.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\ipfs-core\src\components\libp2p.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\ipfs-core\src\components\storage.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\ipfs-core\src\components\index.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\ipfs-core\src\index.js
- C:\Users\parke\Documents\GitHub\xrpl-nft-creator\index.js
   at Function.Module._resolveFilename (internal/modules/cjs/loader.js:885:15)
   at Function.Module._load (internal/modules/cjs/loader.js:730:27)
   at Module.require (internal/modules/cjs/loader.js:957:19)
   at require (internal/modules/cjs/helpers.js:88:18)
   at Object.<anonymous> (C:\Users\parke\Documents\GitHub\xrpl-nft-creator\node_modules\bcrypto\lib\native\binding.js:11:17)
   at Module._compile (internal/modules/cjs/loader.js:1068:30)
   at Object.Module._extensions..js (internal/modules/cjs/loader.js:1097:10)
   at Module.load (internal/modules/cjs/loader.js:933:32)
   at Function.Module._load (internal/modules/cjs/loader.js:774:14)
   at Module.require (internal/modules/cjs/loader.js:957:19)
something went wrong, press Enter to exit script...

I looked in the index.js file and could not find anything named 'loady' so I'm kind of at a loss here.
I watched your Demo @ https://www.youtube.com/watch?v=0aNBpp-2R1w and couldn't get past that error.
Did you run into this problem and do you know how I could fix it?
Thanks

Hello @parkerburchett , I did not run into that issue, however I did run into another issue that could be related.
Please pull the latest copy of the code base:
git clone git@github.com:calvincs/xrpl-nft-creator.git
npm install
node index.js

Let me know if this solves your issue, or if you get new errors.
Also let me know your version of node / npm / operating system.
As much detail as you can give me will be helpful :-)
Thank you

I'll try that and get back to you.

@parkerburchett Touching base, how is everything looking?

I used
git clone https://github.com/calvincs/xrpl-nft-creator npm install node index.js
That got everything to resolve. Cloning from<EMAIL_ADDRESS>requires authentication while cloning from a URL does not.
 Select NFT build folder to use, located under the input directory... (Press  to submit)`

However, there were no options to choose from.
I added some console.log statements to see what was up in the input directory
async function GetBuildConfig() {
  try {
      //options specific to globSource
      const globSourceOptions = { recursive: true };
      let workOptions = [];
      //look for all build directories
      let inputDir = __dirname + path.sep + 'input'; // This will navigate to the input folder
      console.log(inputDir)
      for await (const file of globSource(inputDir, globSourceOptions)) {
        let pathCount = file.path.split(path.sep).length-1;
        if (pathCount < 3 && pathCount > 1) { // does this say that path count == 2?
          file.path = __dirname + file.path;
          workOptions.push(file);
        }
      console.log(workOptions)
      console.log(__dirname)
      }

And got as output:
` __  __         _    _  _ ___ _____     ___              _
\ / /_ _ _ __| |  | | | _|   _|   / _| _ ___ __ | | ___ _ _

<| '| ' \ |  | . | _|  | |    | (__| '_/ -_) _ |  / _ \ '|
//__| | .__/|  ||_||   ||     ___|| __,|___/|
||
2021-06-01 17:18:16 [info]:     starting IPFS node for content distribution
Swarm listening on /ip4/<IP_ADDRESS>/tcp/64267/p2p/QmbVPD3y19ZzR1jJwFQzyGiwVtZ5w9E62HRbzgyRK8bbYL
2021-06-01 17:18:17 [warn]:     DO NOT USE THIS IN PRODUCTION, THIS IS A Proof Of Concept
2021-06-01 17:18:17 [warn]:     Use the XRP TestNet for testing
2021-06-01 17:18:17 [warn]:     You can get a XRP Test account here: https://xrpl.org/xrp-testnet-faucet.html
By pressing enter, you agree and understand this is a Proof of Concept, and SHOULD NOT be used for production!
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator\input
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
[]
C:\Users\parke\Documents\GitHub\retesting xrpl nft creator\xrpl-nft-creator
? Select NFT build folder to use, located under the input directory... (Press  to submit) `

There might be a difference in the way that file path are written on OS vs Windows. That's my guess at least.
I'm tagging Cameron, we're both on a team trying to build a NFT platform on XRP. @cameronheinlein

Thanks @parkerburchett I will test this on Windows, see if I can replicate your issue / correct it.

I have identified the issue(s) and will have a windows specific fix patch released in a few days.
It does have to do with Windows Paths vs Nix paths.

Sorry this has taken awhile.
Testing on Nix and Windows 10
Let me know how it goes for you :-)

To be clear, the latest push to main has fixes for Windows pathing issues.  :-)

Thanks, I'll test it out.


add enumext compatibility

Lists enumext as compatible and adds several tests. The tests were kindly provided by @pablgonz as part of the documentation. The package hand-tunes the tagging so it would probably be good if someone else took a look at this too.

I'm not 100% percent sure about the generated tagging. It  doesn't look wrong, but there are some aspect that I think aren't quite right (or intended).  For example, if there is text directly in front of a list (not in your exaple but one could change that) then I would expect that text + the list becoming part of a single <text-unit> consisting of <text> followed by <list>  but instead one gets always two <text-unit>s, which implies that there is an empty line before the list.  For example

I also saw some <Div> which I don't see why they appear, e.g.,  here:

comments @u-fischer, @pablgonz ?

@FrankMittelbach I can not reproduce your output. The tagging looks ok. Can you show the file you compiled and the log-file?

@FrankMittelbach @u-fischer Hi, first of all thanks for taking the time to look, I did the comparison tests using the standard enumerate environment provided by LaTeX, my version of Acrobat DC is quite old so I don't see the same output, but with ngpdf the comparison is the same.
\DocumentMetadata
  {
    lang=en-US,
    pdfversion=2.0,
    pdfstandard=ua-2,
    testphase={phase-III,math,title,table,firstaid},
    uncompress,
  }
\documentclass{article}
\usepackage[top=2cm,bottom=2cm,left=1cm,right=1cm]{geometry}
\usepackage{unicode-math,hyperref,enumext}
\hypersetup
  {
    colorlinks = true,
    pdftitle   = {Test tagged PDF for enumext package},
  }
\begin{document}
\section{only enumext}
Some text here \begin{enumext}[labelwidth=1cm,labelsep=0.25cm,align=left, wrap-label=\textbf{(#1}, label=\arabic*.)]
  \item This text is in the first level.\label{A}
    \begin{enumext}
      \item This text is in the second level.\footnote{foot note in enumext}
        \begin{enumext}
          \item This text is in the third level.
            \begin{enumext}
              \item This text is in the fourth level.\footnotemark[20]
            \end{enumext}
        \end{enumext}
    \end{enumext}
  \item[X] This text is in the first level.
  \item* This text is in the first level.
\end{enumext}

Some ref here \ref{A}\footnotetext[20]{foot note in enumext [20]}

\end{document}

\DocumentMetadata
  {
    lang=en-US,
    pdfversion=2.0,
    pdfstandard=ua-2,
    testphase={phase-III,math,title,table,firstaid},
    uncompress,
  }
\documentclass{article}
\usepackage[top=2cm,bottom=2cm,left=1cm,right=1cm]{geometry}
\usepackage{unicode-math,hyperref,enumext}
\hypersetup
  {
    colorlinks = true,
    pdftitle   = {Test tagged PDF for standar enumerate},
  }
\begin{document}
\section{only enumerate}
Some text here \begin{enumerate}
  \item This text is in the first level.\label{A}
    \begin{enumerate}
      \item This text is in the second level.\footnote{foot note in enumext}
        \begin{enumerate}
          \item This text is in the third level.
            \begin{enumerate}
              \item This text is in the fourth level.\footnotemark[20]
            \end{enumerate}
        \end{enumerate}
    \end{enumerate}
  \item[X] This text is in the first level.
  \item* This text is in the first level.
\end{enumerate}

Some ref here \ref{A}\footnotetext[20]{foot note in enumext [20]}

\end{document}

For the second question regarding <DIV>, the comparison (due to the implementation of enumext*) is as follows:
\DocumentMetadata
  {
    lang=en-US,
    pdfversion=2.0,
    pdfstandard=ua-2,
    testphase={phase-III,math,title,table,firstaid},
    uncompress,
  }
\documentclass{article}
\usepackage[top=2cm,bottom=2cm,left=1cm,right=1cm]{geometry}
\usepackage{unicode-math,hyperref,enumext}
\hypersetup
  {
    colorlinks = true,
    pdftitle   = {Test tagged PDF for enumerate+minipage},
  }
\begin{document}
\section{only enumerate}
Some text here

\begin{enumerate}
  \item \begin{minipage}[t]{\dimeval{\linewidth-\labelwidth-\labelsep}} This text is in the first level. \end{minipage}
  \item[X] \begin{minipage}[t]{\dimeval{\linewidth-\labelwidth-\labelsep}} This text is in the first level. \end{minipage}
\end{enumerate}

\section{only enumext*}
Some text here

\begin{enumext*}
  \item This text is in the first level.
  \item[X] This text is in the first level.
\end{enumext*}

\end{document}

@FrankMittelbach I can not reproduce your output. The tagging looks ok. Can you show the file you compiled and the log-file?

sorry, I confused myself. I put the %in front of the second list but then looked at the first, mea culpa. However looking at the output, the reason I guess I did this was, that the spacing between the test and the first list is shorter than the one between the text and the second, which I took as a sign that the first list is part of the same paragrap. However, that spacing differenceseems to be just a difference between enumext and exnumext* (not sure it is deliberate, but it has nothing to do with tagging). So yes, tagging is fine and thanks for the explanation where the Div comes from.

@FrankMittelbach I can not reproduce your output. The tagging looks ok. Can you show the file you compiled and the log-file?

sorry, I confused myself. I put the %in front of the second list but then looked at the first, mea culpa. However looking at the output, the reason I guess I did this was, that the spacing between the text and the first list is shorter than the one between the text and the second, which I took as a sign that the first list is part of the same paragraph. However, that spacing difference seems to be just a difference between enumext and exnumext* (not sure it is deliberate, but it has nothing to do with tagging). So yes, tagging is fine and thanks for the explanation where the Div comes from.

Thanks, you found a problem in my implementation of the base-fix key, the behavior of the enumext* environment is correct (and the standard when topsep is not equal to 0pt), it is already fixed (along with many other things) for the next version.
Thanks for everything
Saludos


red-269 password min requirements

For complexity, we will need to display this to the user as well when they set/change their password
min 8 characters
at least 1 letter
at least 1 number
at least 1 special character


avoid infinite recursion if cls.dict refers to cls

The python pickler does a recursive check through a class's dict to find containing classes. Some classes (issue discovered via typing.List) contain a self-reference within their dict, leading to infinite recursion.
This PR fixes the simple case of a single level of self-reference; checking for mutually recursive classes seems like overkill.

Follow this checklist to help us incorporate your contribution quickly and easily:

[ ] Make sure there is a JIRA issue filed for the change (usually before you start working on it).  Trivial changes like typos do not require a JIRA issue.  Your pull request should address just this issue, without pulling in other changes.
[ ] Format the pull request title like [BEAM-XXX] Fixes bug in ApproximateQuantiles, where you replace BEAM-XXX with the appropriate JIRA issue.
[ ] Write a pull request description that is detailed enough to understand:

[ ] What the pull request does
[ ] Why it does it
[ ] How it does it
[ ] Why this approach

[ ] Each commit in the pull request should have a meaningful subject line and body.
[ ] Run mvn clean verify to make sure basic checks pass. A more thorough check will be performed on your pull request automatically.
[ ] If this contribution is large, please file an Apache Individual Contributor License Agreement.

Thanks for the fix.
We are still having bug in the case where A => B and B => A
Should we handle that case as well.
cc: @robertwb

can someone help with the failing jenkins checks? when i click through for details all i see is "no changes" - are these existing failures?

confirmed that  ./gradlew --info --continue --rerun-tasks :pythonPreCommit fails locally on master

fixed in https://github.com/apache/beam/pull/5072


set whether the nic is managed by NetworkManager be configurable

[x] Make sure you have followed Kube-OVN Code Style.

What type of this PR

Features
Bug fixes

set the nic could be managed by NetworkManager or not
Which issue(s) this PR fixes:
Fixes #2983
WHAT

🤖 Generated by Copilot at c8374a2
This pull request adds a new flag --manage-nic-by-network-manager to the ovn-cni container and a corresponding Helm value MANAGE-NIC-BY-NETWORK-MANAGER to the charts, which allow users to configure whether the ovn-cni plugin should set the network interface link managed by NetworkManager or not. This feature is intended to address the issue #1409, where some users reported network connectivity problems caused by NetworkManager interference.

🤖 Generated by Copilot at c8374a2

To fix an issue with NetworkManager
We added a flag to the ovn-cni container
It sets the link managed or not
Based on the config field we got
And we hope it makes the network smoother

HOW

🤖 Generated by Copilot at c8374a2

Add a new flag --manage-nic-by-network-manager to the ovn-cni container arguments to allow users to configure NetworkManager management of network interface links (link)
Add a new Helm value MANAGE-NIC-BY-NETWORK-MANAGER to the networking section in values.yaml to customize the flag value (link)
Add a new field ManageNicByNetworkManager to the Configuration struct to store the flag value (link)
Parse the flag value from the command-line arguments using the pflag package and assign it to the configuration field (link, link)
Modify the calls to the SetManaged method of the nmSyncer object in changeProvideNicName and transferAddrsAndRoutes functions to pass the configuration field as the second argument, making the ovn-cni plugin respect the user's choice of NetworkManager management (link, link)

@zhangzujian hi, there is a problem when using NetworkManager to manage bond, if set NetworkManager to be false, will cause binding nics split into two nic. could you help review this?

@zhangzujian hi, there is a problem when using NetworkManager to manage bond, if set NetworkManager to be false, will cause binding nics split into two nics. could you help review this?

We can skip NetworkManager operations for bond devices automatically, instead of adding an option to kube-ovn-cni.

@zhangzujian hi, there is a problem when using NetworkManager to manage bond, if set NetworkManager to be false, will cause binding nics split into two nics. could you help review this?

We can skip NetworkManager operations for bond devices automatically, instead of adding an option to kube-ovn-cni.

solution changed

We need further consider this, other networkmanager config like sub interface may also hit the same issue.


State should not be clamped if zero_means_zero is set

The functionality of zero_means_zero was changed in a previous commit, such that 0 would still be clamped to the allowed minimum temperature.
For my boiler this means that if the PID controller does not call for heat, it will still keep the pump running and sometimes heat the water, as a constant 20 degrees is requested.
This commit changes that back, such that 0 will request 0.0 from the boiler, causing the boiler to go into stand-by mode.

You are totally correct, just fixed that!

Actually there has to be some other issue. I just tested it and now it always zeroes the result state no matter what. Will investigate after work.

I just installed the new version, seems to be working for me:
[12:51:13][D][opentherm:188]: Received OpenTherm response with id 56 (DHW_SETPOINT) [12:51:13][D][opentherm:190]: 00000101 00111000 00110111 00000000 type: WRITE_ACK; id: 56; HB: 55; LB: 0; uint_16: 14080; float: 55.000000 [12:51:13][D][sensor:093]: 'Actual temperature': Sending state 22.21000 °C with 2 decimals of accuracy [12:51:13][D][opentherm.output:008]: Received state: 1.00. Min value: 20.00, max value: 85.00 [12:51:13][D][opentherm.output:011]: Output t_set_t_set set to 85.00 [12:51:13][D][sensor:093]: 'PID RESULT': Sending state 525.32806 % with 1 decimals of accuracy [12:51:13][D][sensor:093]: 'PID HEAT': Sending state 100.00000 % with 1 decimals of accuracy [12:51:13][D][sensor:093]: 'PID ERROR': Sending state 579.00012 % with 1 decimals of accuracy [12:51:13][D][sensor:093]: 'PID PROPORTIONAL': Sending state 521.10010 % with 1 decimals of accuracy [12:51:13][D][sensor:093]: 'PID INTEGRAL': Sending state 4.51865 % with 1 decimals of accuracy [12:51:13][D][sensor:093]: 'PID DERIVATIVE': Sending state 0.00000 % with 1 decimals of accuracy

Did you make sure that you actually got the new version when compiling the firmware?

Hi @cnrd! Thank you for fixing this, I totally missed it while reviewing the previous PR.

@cnrd You are correct, I didn't have refresh set up for my external component and so it didnt update. Weird behavior if you ask me, one would expect it would be updating on each build by default.


Check whether a focus state transition occurs

Checking for valid state transitions is necessary because _handleFocusChanged is called when Spinbox are enabled or disabled.
I did not make this pull request when #80 occur because I am not sure what cause the problem.
Now I found that is relative to FocusNode behavior when propery canRequestFocus is changed in TextField. I believe this pull request can close #80.

tracking "previous" state without dealing with didUpdateWidget() tends to result in things getting out of sync when the widget is rebuilt. what if we relied on FocusNode.canRequestFocus instead to avoid our own book keeping? it should be false if the widget is disabled and thus, not focusable, right?
if (_focusNode.canRequestFocus) widget.onSubmitted?.call(value);

I will check sync about didUpdateWidget. But FocusNode.canRequestFocus condition only avoid submit action when disable Spinbox. Enable Spinbox can still trigger submit action.

"enabled" value from SpinBox and CupertinoSpinBox also can't avoid submit action when enable a disabled Spinbox, because "enabled" is always true in this situation.

I will check sync about didUpdateWidget. But FocusNode.canRequestFocus condition only avoid submit action when disable Spinbox. Enable Spinbox can still trigger submit action.

How about something like:
        final oldValue = _value;
        final newValue = fixupValue(_controller.text);
        if (newValue != oldValue && _focusNode.canRequestFocus) widget.onSubmitted?.call(newValue);

So onSubmitted is called only when the value changes, like in setValue.
Change in focus doesn't change value, so it should work for your case too.

I will check sync about didUpdateWidget. But FocusNode.canRequestFocus condition only avoid submit action when disable Spinbox. Enable Spinbox can still trigger submit action.

How about something like:
        final oldValue = _value;
        final newValue = fixupValue(_controller.text);
        if (newValue != oldValue && _focusNode.canRequestFocus) widget.onSubmitted?.call(newValue);

So onSubmitted is called only when the value changes, like in setValue. Change in focus doesn't change value, so it should work for your case too.

Actually, your proposition can cover most case. But a submit aciton is usually tiggered when an input widget lose focus or Enter key is pressed in other UI library, like Qt.
I think we should obey this convention for convenience.

Hi @jpnurmi , I don't think there will be a synchronization problem without dealing with didUpdateWidget() after viewing the code。
hasFocus is property of _focusNode which is final type. _focusNode is determined when state is initilized.
I also move initialization of _hasFocusPrev to initState in new commit. It seems more reasonable.


Get nested namespace

When it tries to get a namespace that contains nested groups, an error is thrown.
Fixed in PR, please merge.

Fixed by #1225


Header dropdown menus block users from interacting with page text in the area

Describe the error
The dropdown menus are always of opacity: 0 even when not being hovered over. They are taking up the space, blocking the page content. I was trying to copy some text from the docs when the dropdown menu popped up. I had to scroll up to position the text at the bottom half of the page to avoid the popup so that I can copy the text.
Link to the page or line
Affecting all pages on the website because it's a global header
Optional - The recommended fix if you have one
When the user hovers over menu items (header menu items / dropdown menu), the dropdown menu should stay.
When the user is only interacting with the page, the popup should not suddenly show up. display: none instead of opacity: 0
Optional - Supporting Screenshots

I see that it's fixed. It works fine now, thanks!


Breaking changes in Treesitter markdown and markdown_inline

Hello,
love your colorscheme, but since the last update of Treesitter there is no highlight in Markdown files,

Looking at the issues, an update of your coloscheme may be required:
Treesitter issue tracker
List of changes
I reverted to v0.9.2 at the moment, but I'd love to continue to use your colorschemes for the next releases. Thanks a lot

Glad you liked, thank you for the heads up, i'll make sure to update the theme!

close #15


Game crashes when holding down keys during a loading screen

Please note: ScriptHookVDotNet is NOT ScriptHookV!
Issue only occurs when ScriptHookVDotNet.dll is installed

Version
Both latest release 3.6.0 and latest main commit f75c4a5
Description
This has been known for years in the speedrunning community but I haven't had the time to investigate it. Originally it was believed that holding down any character switch key during a loading screen causes ScriptHookVDotNet to crash the game (this is used in a glitch called savewarping).
I decided to investigate because I'm planning on using ScriptHookVDotNet for a project. It seems that the game will crash if you hold down any button. This is related to the console and I've pasted an Event Viewer error below (couldn't debug it in VS because the anticheat/DRM crashes the game if you have a debugger attached during a loading screen regardless).
Application: GTA5.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AppDomainUnloadedException
   at SHVDN.Console.DoKeyEvent(System.Windows.Forms.Keys, Boolean)
   at <Module>.?A0xddd40208.ScriptHookVDotnet_ManagedKeyboardMessage(UInt32, Boolean, Boolean, Boolean, Boolean)

It doesn't crash 100% of the time, I loaded successfully once with F6 and twice with U. I tried adding try/catches for the exception but it didn't seem to solve the issue. I'll leave this to someone more experienced to investigate I think.

Man, I wish someone had been found a way to disable anti-debug features that can happen when the game is in the loading screen phase. In that case, the game utilizes them using BeingDebugged in the PEB struct (the game occasionally reads the flag when the game is opening the pause menu).

Man, I wish someone had found ways to disable anti-debug features that can happen when the game is in the loading screen phase. In that case, the game utilizes them using BeingDebugged in the PEB struct (the game occasionally reads the flag when the game is opening the pause menu as well).

You may try scylla hide, I've been using it with C++ (without script hook, though). Game does crash eventually but most of the time it works fine, been debugging for hours without any issue.

I have no issues running the game through Project 1.27 with build f75c4a5. Tried it on two different devices and installed a random mod to see that it's not caused by loading mods. Perhaps you have a mod that isn't compatible with 1.27?

Worth noting that the hold key crash also happens on the latest patch, so the issue is not dependent on game version

I believe this issue exisited long before, but now that the memory scanning is done when loading appdomain, the problem surfaces
The static gc reference ScriptHookVDotNet::domain and ScriptHookVDotNet::console wasn't set to null before unloading, which makes them points to remoting objects in unloaded AppDomain, causing AppDomainUnloadedException in the keyboard handler. It wan't that noticeable before becuase AppDomain unload/reload itself doesn't take much time.
Porbaly can be fixed by setting them to null before unloading 6b6191f4c2b8f98f8fa362a72f0285eb216089b2, or just catch the exception.

Ah, I wasn't catching for all occurrences of console and domain, that's why it wasn't working! Can confirm that both catching the exception and setting them to null work. The latter seems cleaner to me

I haven't managed to run the game through Project 1.27 yet, but still I could reproduce the issue in the latest patch b2845 before merging #1192.

Just noting that the issue seems to be fixed with #1192 but out of nowhere I've started to experience the Project 1.27 crash on one of my two devices. Really weird because I'm almost confident it worked before when I tested f75c4a5. On my other device both 3.6.0, f75c4a5 and 5c368c3 work fine. I'll probably open another issue about it

I just Identified what commit made SHVDN being imcompatible with Project 1.27. It's ee58753. You can track the issue in #1202.


Provide config when starting the coordinator

This was briefly discussed internally today. The node having a hard build dependency on config.json (and security.json for now) existing is not ideal. The idea for now is to move this to the coordinator.
So, instead of starting the coordinator as:
import { config } from '../core/src/config';

await coordinator.start(config.nodeSettings);

it would be called as something like:
await coordinator.start({ config });

where config is being passed in by the deployer or the cloud provider (Lambda) itself on each invocation. This will probably need some experimentation to get right.

I'll wait for you to implement the local version and I'll match that at the deployer. I don't want to break the tests.


pip install problem in python 3

I used pip install django-mailgun to add the app to my Django project.
It seems the code in pip is not synced with github.
try:
from cStringIO import StringIO
except ImportError:
from StringIO import StringIO

Having this issue also. Please fix this!

This is fix in master. You can install it like this:
$ pip install git+git://github.com/BradWhittington/django-mailgun@master

Cool, thanks so much. Will give that a shot. :)
Would there be a possibility to implement a way for emails to be queued using celery or something? So that the user request flow isn't affected on mailguns API response time? Any ideas?

That's what I do, but here is not the right place to ask this as it's not related to the issue.
go to #django irc. Lot's of people there that could help you.

:+1:

This should no longer be an issue. Please reopen if problems continue.


Fix links to code of conduct and contributing guidelines

Summary
I fixed links to the Code of Conduct and Contributing Guidelines that were broken in the documentation.
Requirements (place an x in each [ ])

[x ] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[ x] I've read and agree to the Code of Conduct.

Thanks, @caveness!


⚠ Avatar API Endpoint has degraded performance

In 81af5d7, Avatar API Endpoint (https://avatar.roblox.com/v1/avatar-rules) experienced degraded performance:

HTTP code: 200
Response time: 5005 ms

Resolved: Avatar API Endpoint performance has improved in b30ade9 after 3 minutes.


Should have a means of checking equality of programs

Obviously there are many ways to check equality of Programs, but as a first pass I propose we check to see if they are equal line by line. Thoughts? @willzeng @stevenheidel

Agreed. Let's start with comparing the .out strings to make sure they're the same. We can always iterate in the future. Having program equality implemented like this would make testing easier.

This is a duplicate of #24


Add IConfigurationMonitor to encapsulate Reload behavior

Wraps ChangeToken behavior in a configuration specific monitor
@divega @lodejard what do you guys think about this instead of the current API of directly working against IChangeTokens?

Would this help simplify OptionsMonitor as well?

I'm looking at how this affects logging right now, Options is a bit different since it differs from the normal pattern because it has multiple change token sources its aggregating into one event.

I guess its closer to if we had all of the providers feed into the source, instead of having the providers trip the monitor.  So if we went the other direction with configuration it would be closer to how Options works today


Detect an unavailable connection

I'm trying to create an situation where the user doesn't have a user doesn't have a kafka instance or provides the wrong broker connection using the code in the sample test code in the readme. However each time I run the code, it get's stuck on this line let client = ClientBuilder::new(vec![connection]).build().await.unwrap();. I'm not sure if this has something to do with the backoff configuration with the BrokerConnector::new method.
I know this may seem a silly question but I'm still trying to figure out my way around rust too so I'd really appreciate some assistance with this.

The system is currently designed to eventually converge and retries forever. We could probably add a deadline to the backoff system so user can opt out of that.

I get it now. Is there a reason why Backoff or BackoffConfig is not public? Or maybe users can use the ClientBuilder with some of the BackoffConfig options to configure this.

Currently, the ClientBuilder doesn't accept BackoffConfig.

Raised a PR for BackoffConfig as an option for ClientBuilder here

What do you think about this implementation for a retry limit
// ...
const DEFAULT_RETRY_LIMIT: u32 = 3;
// ...
pub struct BackoffConfig {
    // ...
    pub retry_limit: u32,
}

impl Default for BackoffConfig {
    fn default() -> Self {
        Self {
            // ...
            retry_limit: DEFAULT_RETRY_LIMIT
        }
    }
}

#[derive(Debug, Error)]
#[allow(missing_copy_implementations)]
pub enum BackoffError {
    #[error("")]
    MaxRetry
}

pub struct Backoff {
    // ...
    retry_limit: u32,
}

pub async fn retry_with_backoff<F, F1, B, E>(
        &mut self,
        request_name: &str,
        do_stuff: F,
) -> BackoffResult<B>
    where
        F: (Fn() -> F1) + Send + Sync,
        F1: std::future::Future<Output = ControlFlow<B, ErrorOrThrottle<E>>> + Send,
        E: std::error::Error + Send,
{
        let mut attempt_count = 0;
        loop {
            // ...
            if attempt_count >= self.retry_limit {
                break Err(BackoffError::MaxRetry);
            }
            attempt_count += 1;
            // ...
        }
}

Judging by what I've read here, I think I'll try replicating the implementation you have in the IOx code base. My approach may not be the best after all.

I think we can just copy the code from https://github.com/influxdata/influxdb_iox/tree/main/backoff . License-wise this is OK.


[4.9.6] webpack produces a warning -> "export 'createUnarySpacing' was not found in '@material-ui/system'"

[X] The issue is present in the latest release.
[X] I have searched the issues of this repository and believe that this is not a duplicate.

Current Behavior 😯

WARNING in<EMAIL_ADDRESS>14:18-36
"export 'createUnarySpacing' was not found in '@material-ui/system'
<EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS><EMAIL_ADDRESS>@ ./app/components/OrganizationSignup2/Loading.jsx
Expected Behavior 🤔

No warning.
Your Environment 🌎

Tech
Version

Material-UI
v4.9.6

React
v16.12.0

TypeScript
v3.8.3

@eps1lon Oops, it had to happen! 😆

It should be solved with<EMAIL_ADDRESS>

Looks like the release is there but cannot be installed from yarn/npm yet?

@oliviertassinari @EsoterikStare I can still see this warning in<EMAIL_ADDRESS>


Rounded Squares not matching p5.js and missing tag

Using the square function in p5.js, if you input a corner rounding size greater than half the square size, it caps that value at half the square size, but p5.plotSvg doesn't.
It's also exporting a broken file, missing a closing g tag, this problem goes away if I put a push after beginRecordSVG in my code below.
Expected

SVG Export

  beginRecordSVG(this, "myOutput.svg");

  const cols = 12;
  const rows = 12;
  const step_size = canvas_x/cols;
  translate(step_size/2, step_size/2);
  rectMode(CENTER);

  for(let i=0; i<cols; i++){
    for(let j=0; j<rows; j++){
      push();
      const square_size = lerp(step_size * 0.8, step_size * 0.4, j/rows);
      const corner_size = j*square_size/4;
      translate(i*step_size, j*step_size);
      square(0,0, square_size, random([0,corner_size]), random([0,corner_size]), random([0,corner_size]), random([0,corner_size]));
      pop();
    }
  }

  endRecordSVG();

Hi @lewi0622! Thank you so much for filing this issue.

The rounded-rect-corners-larger-than-half-the-rect-width issue hadn't occurred to me. It's an "unexpected" input, but of course I should have expected that. This is easily fixable; thanks for spotting that problem! I'll get right on it.
The missing </g> tag shouldn't have happened, that is a genuine bug. I will have a look.
More soon,
Golan

Resolved in v.0.1.2.


[Question] Question title

Search before asking

[X] I had searched in the issues and found no similar feature requirement.

Description
连接hive时报 据源其他参数不合法

DolphinScheduler Version
最新版
Additional context
No response
Code of Conduct

[X] I agree to follow this project's Code of Conduct

Kerberos related configurations can be configured in common.properties


Enable sfdx plugins:install to install all plugins listed in sfdx-project.json

Is your feature request related to a problem? Please describe.
More or less: https://github.com/forcedotcom/cli/issues/1966
What are you trying to do
I would like to install multiple sfdx plugins at once using the plugins object located in the sfdx-project.json
Why?

ease the instalation of plugins in a sfdx-project. It should work like dev dependencies in node projects.
reduce the amount of time spent while installing plugins. Currently we have to install one by one. I beleive that this isn't really a big problem because projects usually use just a few plugins.
properly version all plugins required in the project.
get rid of the unsignedPluginsAllowList feature. The cli could use the list of plugins found in the sfdx-project.json.

Describe the solution you'd like
sfdx plugins:install must install all plugins listed in the sfdx-project.json when no arguments/flags are passed

https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_config.htm
You will probably have to redesign the schema of the plugins object because it does not seem to accept package versions. I think it was created for another purpose.
Describe alternatives you've considered
Manual steps or automations that can be removed if you create this feature.
Additional context
N/A

This autimation could be triggered by the postinstall hook

FWIW, I like this idea!

@AllanOricil @ImJohnMDaniel I was searching for a way to install and use sfdx plugins via package.json (so the Node.js way) as well and have just recently documented my findings in this article: https://hutte.io/trails/dependency-management-for-sfdx-projects/.
Would love to hear your thoughts on this.


Fix LICENSE

Signed-off-by: Jean-Pierre Huynh<EMAIL_ADDRESS>

Prowler is Apache 2.0 licensed, and it is specified at github repo level since first day. I don't actually understand this PR, it might be a mistake.

You might want to update the header in the prowler script then because it says:
# This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0
# International Public License. The link to the license terms can be found at
# https://creativecommons.org/licenses/by-nc-sa/4.0/legalcode
#
# Author: Toni de la Fuente - @ToniBlyx / Alfresco Software Inc.

I assumed that CC BY-NC-SA 4.0 was the desired license since it was declared in the main file.

ah ok ok, sorry @jphuynh, my bad, I didn't remember that. I added that license in the prowler file because it is the CIS benchmark guides license. I didn't change it when I created this Github repo. So this PR is correct. Thanks!


Jack hammer sound in New York level

Not sure if this is a bug or not, but in the PC version of THPS2 (happens in vanilla PC as well), you can hear the jack hammer sound all over the place.  Pretty sure that in the PSX and DC versions, you can only really hear it if you are in the corner near the awnings.
Is this something that could potentially be fixed?

there is a non-positional jackhammer in the ambient track for the level (music/LTIX03.dat which can also be played in VLC), you might not remember it as that track only plays when music is not playing.  that being said there is a jackhammer-like sound from the train which is a strange error in the pc version.  i think it's replaying the train sound rapidly

Yeah that might be what I am referring to. I thought it was a taxi at first making it.


[HOTFIX] More proper error message when interpreter is not binded

What is this PR for?
Minor fix for more proper error message when interpreter is not binded
What type of PR is it?
[Bug Fix | Improvement ]
Todos

[ ] - Task

What is the Jira issue?

NO jira created

How should this be tested?

CI pass

Screenshots (if appropriate)
Before

After

Questions:

Does the licenses files need update? No
Is there breaking changes for older versions? No
Does this needs documentation? No

hey @zjffdu thanks for making all these improvements, could we make sure there is at least one review before merging?
@Leemoonsoo


Add Soar language support

This PR adds Soar language support to pygments.

[x] One test currently fails, since two functions (ifeq and force-learn) are not recognized as Name.Functions in macros.txt. Any suggestion why this only appears for the two functions in builtin_macros in soar.py?

This is the test output:
================================================================ FAILURES =================================================================
_____________________________________________________ tests/snippets/soar/macros.txt ______________________________________________________
The tokens produced by the "soar" lexer differ from the expected ones in the file "tests/snippets/soar/macros.txt".
Run `tox -- tests/snippets --update-goldens` to update it.

  Skipping 915 identical leading characters in diff, use -v to show
  - ce-learn' Name.Function
  + ce-learn' Literal
    '\n    '      Text.Whitespace
  - 'ifeq'        Name.Function
  + 'ifeq'        Literal...

  ...Full output truncated (36 lines hidden), use '-vv' to show
========================================================= short test summary info =========================================================

Related: https://github.com/SoarGroup/SoarGroup.github.io/issues/24
Looking forward to your feedback!

There's a comma missing after 'force-learn' :)

Thank you for the hint...!
The test should pass now.

@birkenfeld do you need anything else for this PR to move forward? Sorry for the ping.

We are using moschmidt's fork on the Soar website to highlight Soar code now: https://soar.eecs.umich.edu/soar_manual/04_ProceduralKnowledgeLearning/#explanation-based-chunking. It looks good to us! Please let us know if this needs any further review or changes. We would be very happy to see this merged so we could use the pygments release instead of a fork.


CSS clash

I am using Mermaid with Moodle. On the Moodle course and top pages it creates and styles lists of items via a css class called "section." However Mermaid also attempts to style a css class called "section." The result is that the entire course page, or some parts of the front page are rendered with opacity 0.2 and basically become invisible.
Is it possible to be more specific when applying the mermaid CSS styles or prefix them with a mermaid identifier e.g "mermaid_section?"

Thanks for the feedback. I will take a look.

@knsv I'm also experience this. Let me know if you'd like me to address it.

@crodriguez1a You are very welcome to take a look. It would be much appreciated.

@knsv Sure. Not a problem. Assign.

https://github.com/knsv/mermaid/pull/577 should resolve this.

It has been fixed.


GraphQL docs say mention pagination, which doesn't work as expected

https://buildkite.com/docs/graphql-api#relay-compatibility mentions:

The Buildkite GraphQL API adheres to the Relay Specification, which defines standards for querying paginated collections ("Connections" and "Edges")

The pagination doesn't seem to work though. I can see that the number of builds returned is limited to 500, however the pageInfo element never sets hasNextPage to true. Even though BuildConnection.count is higher than the number of returned edges.
This may be either a lack of documentation about how to handle paging results, or a bug in the implementation.

Hey @viraptor, I'm sorry you ran into trouble with this 😔It's definitely a bug, it's just that one connection that doesn't paginate properly. It's on our list to fix it up 👍🏻
If there's something specific you're trying to get that's over the 500 builds limit, drop us an email at<EMAIL_ADDRESS>and we can help you sort it out.
I'm going to close this for now, but if you have any other questions, or suggestions for the docs feel free to re-open it.

Hey, any update on this?
I'm Wondering if this is still broken or I am doing sth wrong. :)


Update groups-concept.md

Minor grammer update

@egullbrandsson : Thanks for your contribution! The author(s) have been notified to review your proposed change.

Looks good; thanks @egullbrandsson.


Make optional removing comments

It could be useful for sites like https://userstyles.org/ where its templates should be like this /*[[template]]*/
It won't work if you just add ! after an asterisk (like in a special comment).

I think we can handle them in an intelligent way, see #369 and #963.

waiting for the update

Won't fix as clean-css is going into maintenance mode.


fix(discord): gateway api version

Codecov Report

Merging #119 (d95a7e9) into master (108b98e) will not change coverage.
The diff coverage is n/a.

:exclamation: Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more.
@@           Coverage Diff           @@
##           master     #119   +/-   ##
=======================================
  Coverage   81.83%   81.83%
=======================================
  Files           1        1
  Lines         424      424
  Branches       86       86
=======================================
  Hits          347      347
  Misses         77       77


Run errors

Dear Sir,
I tried to run the code using Canopy and found the following issue. Can you please guide me how to tackle them. I am a newbie for Phython. Kind regards,
Issue:
ImportError                               Traceback (most recent call last)
C:\Users\200TW\Downloads\ppdd-master\ppdd-master\ppdd_gui.py in ()
1 import sys
2 import os
----> 3 from PyQt5.QtWidgets import *
4 from PyQt5.QtGui import *
5
C:\Users\200TW\AppData\Local\Enthought\Canopy\App\appdata\canopy-<IP_ADDRESS>48.win-x86_64\lib\site-packages\IPython\external\qt_loaders.pyc in load_module(self, fullname)
45     Importing %s disabled by IPython, which has
46     already imported an Incompatible QT Binding: %s
---> 47     """ % (fullname, loaded_api()))
48
49 ID = ImportDenier()
ImportError:
Importing PyQt5 disabled by IPython, which has
already imported an Incompatible QT Binding: pyside

This seems to be a problem with IPython. Qt, which is a C++ GUI library, has two python bindings: PyQt and pyside, for historical and licensing reasons. These two bindings are incompatible with each other. I use PyQt for this project, but your IPython seems to import pyside on start, which blocked PyQt form functioning.
So in short: try running ppdd_gui from plain python and see if this error persists.


Don't call controller constructors on route setup

WHY
BEFORE - What was wrong? What was happening before this PR?
To setup the routes, we initialize a new controller instance and that's causing issues.
Technically speaking what we are doing is initializing controllers at a provider level, and by that time, we can't be sure that all the providers have their services setup, and that prevents developers from reliably injecting services on their controllers as reported in #5379
AFTER - What is happening after this PR?
We initialize the controller instance but without constructor, we don't need the full instance to setup the routes, as all parameters are provided to those functions. Those functions shouldn't be part of the CrudController anyway, the controller should only be constructed in full when certain route is requested. If part of the CrudController, they should def. be static.
We can decide next version if we completely remove it, make them static or whatever.
I used reflection to get the class methods, I think it's a pretty straightforward way to also allow to call protected methods outside of the class scope, like the setupXXXRoutes().
The controller will be constructed later by Laravel when you access the controller routes, as expected, not at the Provider level.
HOW
How did you achieve that, in technical terms?
The setupXXXRoutes are protected methods that can be overwritten so a direct change to the method would be a BC.
The way I found to work around the BC is by using php attributes. We introduce now a #[DeprecatedIgnoreOnRuntime] that tell backpack, and developers, that function is deprecated.
We still call the function the backwards compatible way if we don't find that attribute in the function, meaning developer is using an overwritten CrudPanel or has overwritten the setupRoutes method in that some crud controller.
In case we find that attribute, we just use the instance without constructor, avoiding constructing controller at the wrong application lifetime.
Is it a breaking change?
I hope I made it non-breaking
How can we test the before & after?
in any crud controller, put on the __construct() Log::info('constructed'). See your logs after you access one of those controller routes.

Tested, it's working.
It shouldn't be a breaking change with the new DeprecatedIgnoreOnRuntime attribute 👌


[WIP] Mixed subtree processing

Codecov Report

Merging #981 (0dd71a2) into master (d896651) will not change coverage.
The diff coverage is 100.00%.

@@            Coverage Diff            @@
##            master      #981   +/-   ##
=========================================
  Coverage   100.00%   100.00%
=========================================
  Files           36        36
  Lines         2334      2407   +73
=========================================
+ Hits          2334      2407   +73


FINERACT-1964: Add functionality to calculate maturity amount before creating FD account

Created a functionality to calculate maturity amount. I have tried to follow all the best practices in my knowledge. Please let me know if any changes need to be done. Also, please feel free to check business logic to calculate the amount and the validation operations on the input, because I used my own knowledge and some research to write them.
Current Business logic to calculate the interest:
Maturity amount = P* ((1+ r/n) ^nt))
Where -
A  denotes the future valuation of the investment made
P  denotes the Principal amount
r   denotes the interest rate
n  denotes the number of times interest gets compounded per period
t   denotes the time period the money was invested
Current Applied validations on input data:

All input fields (Principal Amount, annualInterestRate, tenureInMonths, interestPostingPeriodInMonths, interestCompoundingPeriodInMonths) must be greater than 0 and cannot be null.
0 < interestCompoundingPeriodInMonths <= 12

Thanks!

Dear @adamsaghy ,
I have made the changes as suggested. Kindly, review.

@GoyalRocks007 Please squash your commits. The rest looks okay

Hello @adamsaghy,
I have made the required changes. Please review.


Simplify build process to allow construction of a single manybugs scenario.

Chris seems to think that "Rake" is the answer here and I believe him.

Implemented new custom build system. All interaction with RepairBox is carried out via the "repairbox" client executable. This executable is responsible for building, downloading, uploading, and launching bug scenarios. I'm also adding a few simple functions for querying bug scenarios (for now, it's just limited to listing all available bug scenarios).
To add a new bug scenario, contributors just need to drop in a ".bug.yaml" file :-)

Finished implementing new build system.
Users can also download pre-built boxes from the command line using the following command:
$ repairbox download manybugs:python:blah-blah


[Feature] Update instructions

This tutorial is now outdated and cannot be completed as described

@Outsourced-Logic Thanks for the issue! We are actively in the process of updating our courses, so it'll get a refresh soon!
I'm going to go ahead and close this issue as we are tracking our course updates internally 💛


Job priorities are sometimes not honored

There was at least one situation lately were the scheduler was running a job even though a higher priority job in the same queue was available.

The scheduler has been rewritten since this bug was filed, closing it.


Clipping thresholds to input range + 1?

I am facing the AssertionError: Thresholds can't be expressed with type INT8 (the assertion is here in the weight file generation of Thresholding_Batch), which I cannot really explain, at least I cannot see how I end up with a threshold of 128 at the upper bound, except for these lines in the RoundAndClipThresholds transformation: https://github.com/Xilinx/finn/blob/f2424e7fa9bb834f192bdec632bbdebb84b64fb1/src/finn/transformation/streamline/round_thresholds.py#L59-L66
I wonder whether clipping thresholds to the range (idtype.min() - 1, idtype.max() + 1), under the condition that at least one threshold is outside of this range, still guarantees that these thresholds are outside of the range which can be represented with idtype? Why is it clipped to one below/above the valid range? Is there any reasoning which I fail to see? Maybe clipping to (idtype.min(), idtype.max()) would be correct?

See this related issue: https://github.com/Xilinx/finn/issues/875
Doesn't seem like the clipping issue itself was ever resolved.

Hm, the proposed step_minimize_bit_width is already part of the flow, but it comes only after the step which is failing: It is failing right before at step_apply_folding_config. Of course I will try to flip the order of the build steps, but this is the order of the standard data flow build. It will certainly allocate an extra bit (so it is not really minimizing but increasing the bit-width) for the thresholds tensor just to accommodate this clipping? Without a convincing argument, this does not sound right to me...

I actually faced the same issue today when trying to build the ResNet50 from the examples repository, so the clipping issue is still there and has to be worked around in the RoundAndClipThresholds transformation.

Some new insights on this one:

I still do not think the extra +1 range makes sense, but it might have concealed some actual bugs.
The simple fix of removing the +1 from the range solves the problem for our use cases, but it breaks the Mobilenet v1 test case, so this behavior somehow seems to be relevant (but see 1., I think there is something else going on).
The Mobilenet v1 test breaks at test_end2end_mobilenet_minimize_bit_width, which incidentally is what has been proposed as the solution in #875.
The new error looks similar to to the one I have initially reported, i.e., it is at some DataType.allowed query.
This, hints at some rounding and/or representability issue. The range +1, by effectively introducing an extra bit of precision (after "minimizing" the bit-width), probably concealed this issue in most of the cases.

So I started digging a bit and nothing seemed to make any sense at first: See here, for example, close to where the Mobilenet test fails, after removing the +1 from the range: https://github.com/Xilinx/finn/blob/766e9fb47f0c31e82c45cfb9384d1ced8b1ddf7a/src/finn/custom_op/fpgadataflow/thresholding.py#L136-L137 As far as I understand this piece of code, thresholds and threshold_tensor should contain exactly the same values and differ only in shape or by repeating these values, i.e., get_hw_compatible_threshold_tensor can be seen as a more fancy reshape operation. But they actually differ in the values they contain, in particular in the maximum and minimum, i.e., the range of values they contain. Next, the minimized DataType gets derived from the thresholds but this is then tested against the threshold_tensor, causing the assertion to fire as the ranges do not align. However, I do not see anything inherently wrong with the minimize_accumulator_width method (though it seems slightly odd to use the get_hw_compatible_threshold_tensor here at all, but apparently this helps spotting these weird types of errors).
Next step was to figure out why these two tensors end up with different values/value ranges: First hint was the "container" data type of these tensors - normally FINN stores most parameter tensors (even the low bit-width, quantized integer ones) in float32 containers. However, somehow the thresholds initializer ended up as float64 and at https://github.com/fastmachinelearning/qonnx/blob/c5bd87f05e0b6ac6bc578d38161e7dceec1077d9/src/qonnx/util/basic.py#L135 called by the get_hw_compatible_threshold_tensor type-casts back to float32.
Why should we care about this for supposedly integer thresholds? Well, large integers cannot be exactly represented in floating-point and the largest integer (of a given bit-width) which can be represented, depends on the floating-point precision. See for example the largest signed 32-bit integer: While np.float64(2**31-1) == 2**31-1 yields True, i.e., we can represent this one exactly in 64-bit floating-point, np.float32(2**31-1) == 2**31-1 yields False, i.e., it cannot be represented in 32-bit floating-point. This is the reason why after get_hw_compatible_threshold_tensor type-casts back to float32, the values and the range sometimes differ, depending on the particular values in those tensors.
And this lead me back to the RoundAndClipThresholds transformation:

For large integer thresholds coded as floating-points, np.ceil, used for rounding the thresholds, might show some unintuitive behavior: np.ceil(np.float32(16777217)) == 16777216. There is nothing we can do about this, this is just how floating-point behaves. We just need to be aware of this fact and the potential loss of precision.
Depending on the input combination, np.clip might sometimes promote the output to float64, indeed clipping the values to the specified range, but increasing the precision and thus effectively increasing the range of integers which can be represented exactly. This is where the discrepancy described above comes from, and this is something we can do something about: Clearly define the type-casting/type-promotion behavior of the RoundAndClipThresholds transformation.

For now, to not interfere with the rest of FINN and qonnx, I propose to explicitly cast the thresholds after rounding and clipping (back) to float32. It could also be an option to consider float64 or int64 (avoiding the representability issue) as a "container" data type for (large) integer thresholds, but this would require to carefully check all parts of FINN and qonnx currently assuming float32 here.
I will soon open up a PR with a reworked RoundAndClipThresholds transformation as well as test-cases hopefully capable of validating the rounding, clipping and type-casting behavior of this transformation


add project section to pyproject.toml, closes #10760

Description: add project section to pyproject.toml
Issue: closes #10760
Dependencies: None
Tag maintainer: @hwchase17
Twitter handle: None

see response on issue - i think youre trying to install in the wrong place


[Bug] Docs fail to generate with ambiguous 503

Describe the bug
When I ran fern generate --docs from CI, I got a 503 error that "Absolute filepaths to upload: ...":

When I ran it a second time from my local machine, the generation was successful.
To reproduce
Re-run: Link

moving to linear to track this


@libs/xml produces invalid output when ampersands are used in "#text"

https://www.w3.org/TR/xml/ 2.4 Character Data and Markup

The ampersand character (&) and the left angle bracket (<) MUST NOT appear in their literal form, except when used as markup delimiters, or within a comment, a processing instruction, or a CDATA section. If they are needed elsewhere, they MUST be escaped using either numeric character references or the strings " & " and " < " respectively. The right angle bracket (>) may be represented using the string " > ", and MUST, for compatibility, be escaped using either " > " or a character reference when it appears in the string " ]]> " in content, when that string is not marking the end of a CDATA section.

Reproduction
import * as xml from "@libs/xml";

let obj = {
  "@version": "1.0",
  "@encoding": "utf-8",
  "resources": {
    "string": [
      {
        "@name": "strings",
        "#text": "Passport & Email",
      }
    ]
  },
};

console.log(xml.stringify(obj))
/* output:
<?xml version="1.0" encoding="utf-8"?>
<resources>
  <string name="strings">Passport & Email</string>
</resources>
*/

Thanks for reporting, this should be fixed now


Jekyll alternative HTML task.

Hi guys, I wondered if anybody else working with this package has successfully hooked up Jekyll?
The Jekyll compile isn't the problem, what I can't appear to get working is the BrowserSync reload.
Background

I've removed Numjucks
I've setup the Jekyll src folder as '/src/html'
I've setup the Jekyll dist folder as '/_site/'
I've configured BrowserSyncs' base dir to '_site'
I've modded the html.js task, as below

HTML Task
var config = require('../config')
if(!config.tasks.html) return

var browserSync  = require('browser-sync')
var gulp         = require('gulp')
var cp           = require('child_process');
var exec         = cp.exec;

var htmlTask = function() {
  exec('jekyll build', null, function(err, stdout, stderr) {
    if (err) {
      console.log('Child process exited with error code', err.code);
      return
    }
    browserSync.reload({stream:true});
    console.log(stdout);
  });
}

gulp.task('html', htmlTask)
module.exports = htmlTask

Try removing { stream: true } there.
Alternatively you can pass a files option to browserSync that will tell it to watch a glob and reload if a file there changes. You can add that in the config.json file. If you did, you'd remove references to BrowserSync in this file.

@talbs weren't you messing with this at one point?

Thanks @greypants for the suggestion, I've got this working with just calling an empty browserSync.reload().


Detect Damage-over-time

Such as Contagion, Volley of Curses

Found something when I use Volley of Curses:
Those data come from "S_CREATURE_CHANGE_HP" Opcodename
First tic of the dot:
98-133-174-152-4-0-132-157-4-0-42-251-255-255-1-0-0-0-249-113-9-0-0-128-12-0-169-39-22-0-0-128-0-0-0-0-0
249-113-9-0-0-128-12-0 is the mob ID (target of the dot)
169-39-22-0-0-128-0-0 is my player ID (owner of the dot)
for the other tic, the structure is the same, only that part change:
174-152-4-0-132-157-4-0-42-251
I think that should be related to the hp lost by the mob.
I will search more tomorrow

Any idea where can you find it ? Afaik it isn't in AttackResult packet, but can't find any other packet for it.

I didn't look for it yet.
G___ wrote:

Take a look at dot's. Seems there is no direct way to capture them. One packet setting abnormal status of creature being affected by someone's dot. Then only packets with hp changes (no skillresult, but with id of attacker). And the last packet canceling abnormal status or despawn npc if dot caused death. Not sure, who can see packets with changed hp, may be only those, who've attacked the same mob. If this packets is seen by everybody - they may be counted as dot, if there is no skillresult packet, associated with the same hp delta.


Mailable containing replyTo Address with name shows an RFC 2822 error

Laravel Version: 9.42.2
PHP Version: 8.1.8
Database Driver & Version: mysql  Ver 8.0.29 for macos12.2 on arm64 (Homebrew)

Description:
When sending a mailable with a replyTo address that includes a name, it throws the following error
Email "Name Of Recipient Here" does not comply with addr-spec of RFC 2822.

This seems to be happening due to the combination of Address in replyTo only passing the name value and nullifying the email address.  replyTo is essentially only receiving the name field here.
Steps To Reproduce:

Fresh copy of Laravel
Setup a way to receive email - I am using Helo (from beyondco.de)
Create a mailable and method of firing mailable
In the Envelope add a replyTo entry (per the Laravel docs: https://laravel.com/docs/9.x/mail#using-the-envelope - bottom example)
Send the mailable (via command, route, however)
This error will occur:  Email "Name Of Recipient Here" does not comply with addr-spec of RFC 2822.

Note:  This does not happen if replyTo is inside an array.  I submitted this to the docs as it was tripping me up in a recent Laravel 9 upgrade.  Not sure if this is a bug or if the change made to the documentation before being added is incorrect.  https://github.com/laravel/docs/pull/8370
Repo created to demo issue here:
https://github.com/fylzero/laravel-reply-to-issue
Relevant files are:
app/Console/Commands/SendMailCommand.php
app/Mail/MerpDerpMail.php

In my opinion, it's better to just update the docs, since Envelope expects params to, cc, bcc and replyTo to be an array.
https://github.com/laravel/framework/blob/1dc597098b7c30fb71cde8247c5f9a91e84e021b/src/Illuminate/Mail/Mailables/Envelope.php#L92
When passing an Address object directly to replyTo, normalizeAddress is getting mad.

@PerryvanderMeer Thanks for confirming and resubmitting that!

Docs have been updated, thanks again @PerryvanderMeer


Data process

[ ] Created model classes for all entities as shown in the [ERD diagram]
[ ] Used models to insert data
[ ] Set up associations between models
[ ] Created custom methods

A method that returns the 3 most recent posts for a given user.
A method that updates the posts counter for a user.
A method which returns the 5 most recent comments for a given post.
A method that updates the comments counter for a post.
A method that updates the likes counter for a post.

Invalid Code Review Request ❌
Hi @touredri,
While you made a great effort in this project, unfortunately, I cannot proceed to review your code.
You have submitted a project, that fails in linters. Please fix it.
Your Code Review Request will be marked as invalid in your Dashboard, so please submit a new one once you are ready 🙏
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear.
Please, remember to tag me in your question so I can receive the notification.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.

Invalid Code Review Request does not count into the code reviews limit.


Bot emulator crashes when clicking on Action

I added an attachment with actions similar to how its described at the bottom of this link: http://docs.botframework.com/connector/message-actions/#navtitle
It works fine for displaying my action items in the bot emulator but as soon as I click on one of the options it crashes. I presume it isn't properly null checking and I am not providing a url.

Sorry for the delay in responding.  Added @LarsLiden who should be able to comment.

Closing this issue due to age. @v-tbert - please open a new issue if this issue is not fixed and needs further discussion. Thanks!


TODO points for 1.0

Let's release 1.0 finally at some point :tada:
Some TODO points:

[ ] https://github.com/thanos-io/thanos/pull/5607/files#diff-b484a14e04378ca9ecf288d24b5dd433576ff59e3e602734d3c568beb89bc456L58 convert all fields to millisecond precision -> not sure if this is actually needed since I don't think that we will ever have sub-second lookback delta or block resolution :thinking:
[ ] Remove deprecated fields from protobufs && deprecated command line flags (https://github.com/thanos-io/thanos/search?q=deprecated)
[ ] Remove deprecated STACKDRIVER tracing provider
[ ] Remove pkg/query/internal/test-storeset-pre-v0.8.0/storeset.go ?

Possible:

[ ] Move to OpenTelemetry for tracing?
[ ] Enable all experimental features by default?

Maybe anything else?

I wonder if we should also try to complete the deletion story somehow. Anecdotally, it seems a lot of users are asking about it (e.g. from yesterday https://cloud-native.slack.com/archives/CK5RSSC10/p1663695281723309) and we have couple of proposals in place to do this in store / compactor (https://github.com/thanos-io/thanos/issues/1598, https://github.com/thanos-io/thanos/pull/5436), but this work has not been finalized yet.

Let's remove this field before 1.0 IMO https://github.com/thanos-io/thanos/pull/5709

I've opened https://github.com/thanos-io/thanos/issues/5719 to discuss some dedup improvements. If we make any changes to StoreAPIs, it would be nice to introduce them prior to v1 and avoid maintaining code for backwards compatibility.


Installer never finishes

The installer is stuck for the past 8 hours here:

As you can see behind the log has the InternetSetOptionW problem.
How did you overcome this stage?

Having a similr problem, stuck at MS SQL Server installation :(

Similar problem, stuck at Visual Studio Tools 2015, increases 1% at 15 min and is not freezed but the task is the same.

Have you tried pressing enter many times in the terminal window?

on another note there's another way to install sw. Create an admin image and then install swwi/data/solidworks.msi using wine msiexec /i <path to solidworks.msi>. Again at some point it seems to hang but press enter many times and it'll go
Note: you need wine-git for this to work and winetricks -q dotnet48 vcrun2019 d3dcompiler_47 corefonts. For more check this comment (and maybe the whole issue)

Similar problem, stuck at Visual Studio Tools 2015, increases 1% at 15 min and is not freezed but the task is the same.

Did you ever get this fixed? I am in the same boat I think, although mine seems to eventually be going.

I too have been running the installer now close to 20hr and seems hung at 81%. Enter key does nothing
In the terminal output the below is what it repeditive.
05b4:err:sync:RtlpWaitForCriticalSection section<PHONE_NUMBER>06CCA0 "../wine/dlls/ntdll/thread.c: fls_section" wait timed out in thread 05b4, blocked by 0598, retrying (60 sec) [user@archlinux Downloads]$ 0128:err:ole:com_get_class_object class {6c736db1-bd94-11d0-8a23-00aa00b58e10} not registered 0128:err:ole:com_get_class_object no class object {6c736db1-bd94-11d0-8a23-00aa00b58e10} could be created for context 0x1 0128:err:ole:com_get_class_object class {6c736db1-bd94-11d0-8a23-00aa00b58e10} not registered 0128:err:ole:com_get_class_object no class object {6c736db1-bd94-11d0-8a23-00aa00b58e10} could be created for context 0x1 0128:err:ole:com_get_class_object class {6c736db1-bd94-11d0-8a23-00aa00b58e10} not registered 0128:err:ole:com_get_class_object no class object {6c736db1-bd94-11d0-8a23-00aa00b58e10} could be created for context 0x1 0128:fixme:shell:DllGetClassObject failed for CLSID={ff393560-c2a7-11cf-bff4-444553540000} (History) 04c8:fixme:tbs:Tbsi_GetDeviceInfo (16, 00007FFFFF27FC00) stub 05b4:err:sync:RtlpWaitForCriticalSection section<PHONE_NUMBER>06CCA0 "../wine/dlls/ntdll/thread.c: fls_section" wait timed out in thread 05b4, blocked by 0598, retrying (60 sec)
Software Info
Distro: Arch(fresh install)
DE: XFCE4


How to visualize the map data?

Is there a way to visualize the "base_map.bin" file?
There is no record file.

There are several ways!
1)Create a directory under /apollo/modules/map/data/, move your hdmap files into the directory; browse dreamview frontend page, select your map, toggle Sim Control button
if you only have base_map.bin, you should generate sim_map.bin by yourself, use python scripts under /apollo/modules/tools/map_gen
2)Use mapshow.py under /apollo/modules/tools/mapshow
3)Use thirdparty tools, eg: LGSVL/Mathworks Roadrunner

Thank you for your help!
I was able to visualize the map!


Test should be fixed to skip ciao on not-HEAD installations

Backing up one level, do we want some utility in testr that determines if the installation is the HEAD network?  Also maybe HAS_SYBASE.

See https://github.com/sot/testr/pull/18


style of element not updated after hydration

Environment
Nuxi 3.6.2
RootDir: /home/ben/workspace/ceasy/packages/app/web
Nuxt project info:

Operating System: Linux
Node Version:     v18.9.0
Nuxt Version:     3.6.2
Nitro Version:    2.5.2
Package Manager<EMAIL_ADDRESS>Builder:          vite
User Config:      telemetry, modules, tailwindcss, colorMode, typescript, alias, vite, runtimeConfig, experimental
Runtime Modules<EMAIL_ADDRESS><EMAIL_ADDRESS>unplugin-icons/nuxt<EMAIL_ADDRESS>@sidebase/nuxt-pdf
Build Modules:    -

Reproduction

<template>

      {{ heightStyle }}
      {{ mainStyle }}

</template>

Describe the bug
The scaleSize and currentHeight are based on https://vueuse.org/core/useWindowSize/#usewindowsize
So it's normal that during SSR the window size is incorrect, since it's unknown.
The defaults for the props in that case are:
{
  scaleSize: 1
  currentHeight: 794
}

After the hydration however, the above component renders to:

{
  "height": "513.9670710571924px"
} {
  "scale": 0.6473136915077989,
  "transformOrigin": "top"
}

      {{ heightStyle }}
      {{ mainStyle }}

renders correctly, but
:style="heightStyle"

does not get updated.
Additional context
No response
Logs
No response

Can you provide a running reproduction please. The mentioned code is not enough to reproduce the issue.

Can be closed I think due to no response @danielroe

This is a Vue SSR behaviour. Technically it's a hydration mismatch, and will be the case on any Vue 3 SSR project...
You can likely reproduce it here: https://stackblitz.com/github/nuxt-contrib/vue3-ssr-starter.


Bug: typo on vector/README.md

Describe the bug
The 'Vector' page link on vector/README.md does not work.
To Reproduce
Steps to reproduce the behavior:

Go to 'vector'
Scroll down and Click on '✔ Vector'
See error (404 Not found)

Expected behavior
Link to correct Vector page
Screenshots

Hey! If this issue is open then can I work on this?

I'm already working on it. Check my pull request here.
Thank you for your consideration. 😄

@yyyoungha already fixed issue check #576

@yyyoungha already fixed issue check #576

I think I fixed this issue first. Check my pull request here.


Implementation of clear button on data-role="taginput"

If possible, the implementation of the clear button on data-role = "taginput" would be really useful.
If there are many elements (see image) to delete the field, without having to define a script associated with a button, you have to delete them one by one.

Thank's!

4.3.5
Metro 4

[x] Tag input: change trigger defining
[x] Tag input: add clear button with attributes clearButton, clsClearButton, clearButtonIcon
[x] Tag input: add attributes clsComponent, clsInput
[x] Tag input: add event onClear

Great work, as usual!
Thank's Olton!

Hi Olton!
If can be useful to you, the clear button seems off-center

Thank's!

Maybe need to update CSS?

Forget to say, I use class="input-small" for field using
 * Metro 4 Components Library v4.3.5  (https://metroui.org.ua)
 * Copyright 2012-2019 Sergey Pimenov
 * Built at 03/12/2019 14:42:42

Thank's!

for small and large I will add styles tomorrow. Unfortunately, I feel bad about myself.

I'm very sorry.
First comes health; job comes later.

I added the required styles for small and large sizes

Perfect!
Very Thank's


Create install.sh

Bash installation script for ubuntu

Another option to install Python 3.5 on Ubuntu: ppa:fkrull/deadsnakes
https://www.reddit.com/r/IPython/comments/3lf81w/using_python35_in_ubuntu_trusty/


[WFLY-17043] /subsystem=iiop, realm needs to deprecated and rejected at runtime

https://issues.redhat.com/browse/WFLY-17043
And model bump:
https://issues.redhat.com/browse/WFLY-17044

Thanks @darranl

@tadamski +1 is needs to be fail in stage Runtime as we still need to support mixed domain mode where these attributes will be read in the primary host controller to manage older secondaries.


map_blocks with dtype induce dummy function call (Doc say it shouldn't)

dask.array.map_blocks says about dtype:

The dtype of the output array. It is recommended to provide this. If not provided, will be inferred by applying the function to a small set of fake data.

So if dtype is provided, the function should not be called.
This minimal example will print a message if the function is called:
import dask.array as da

def block_func(block,block_info=None):
    if block_info is None:
        print("block_func called with block_info=None")
    return block + 0.5

data=da.arange(10,chunks=2)
data.map_blocks(block_func, dtype='f8')

This code print "block_func called with block_info=None", and that show that the function is called, despite of the documentation.
I've found that using the undocumented keyword meta=True, it's work as expected, and the function is not called:
data.map_blocks(block_func, dtype='f8',meta=True)

Is it a documentation problem, or am I missing something else ?
Environment:

Dask version: 2.28.0
Python version: 3.8.2
Operating System: linux
Install method (conda, pip, source): pip

Thanks for the report. The docs will need to be updated, but we might want to also update the behavior.
Previously, we only used dtype. Then we added support for using meta to specify the concrete container (numpy, cupy, sparse, ...) (https://github.com/dask/dask/pull/5269). Right now the behavior is to not call the function only when both meta and dtype are specified. We have a few options:

Just update the docs. Instruct users to specify both dtype and meta
Update the implementation to restore the old behavior. dtype="f8" and no meta would mean a NumPy ndarray with foat64 dtype
Update the docs to encourage passing meta.

I think my preference is for option 2, but would be curious to hear others' thoughts. cc @pentschev if you have thoughts.

I would go for option 1. Currently, we try to infer meta automatically to the best of our abilities, when we go for option 2 we lose that ability. IMO, we should strive to keep this kind of computation automatic when possible, it can be very difficult in a complex pipeline with multiple non-NumPy arrays otherwise.

we should strive to keep this kind of computation automatic when possible, it can be very difficult in a complex pipeline with multiple non-NumPy arrays otherwise.

My perception is probably skewed, but I'm having trouble balancing the cost of specifying meta against how often it'll be used to specify non-NumPy arrays.
How about this modification of option 2: When the user provides just dtype="f8" (no meta) we scan the input arrays in args for arrays. If there's just one type (by far the most common case?) then we set meta to that type with the user-specified dtype. This uses the assumption that most functions would return an array of the same type.
If there's multiple types in args, we issue the warning asking them to clarify meta.
And specifying meta up front would disable the scan over args entirely.

I agree with these two parts:

How about this modification of option 2: When the user provides just dtype="f8" (no meta) we scan the input arrays in args for arrays. If there's just one type (by far the most common case?) then we set meta to that type with the user-specified dtype. This uses the assumption that most functions would return an array of the same type.
And specifying meta up front would disable the scan over args entirely.

But not with:

If there's multiple types in args, we issue the warning asking them to clarify meta.

This last case is indeed what we're trying to solve (emphasis in trying) with automatic meta deduction. If the user needs to always specify the meta type we again ignore this mechanism, and if our intent is to make things easier for complicated cases in the future then we would be going against that goal by doing this.
So my suggestion here would be to address most things as you suggested, except for different args. The complete idea would look something like:
"Specifying meta up front would use that value as meta and no further action is taking to infer its value. When the user provides just dtype (no meta) we scan the input arrays in args for arrays, and if there's just one type then we set meta to that type with the user-specified dtype. If there's multiple types in args but no meta is specified, we infer meta from arrays in args."
Does that look reasonable?

Ah, my apologies, I was confused about the current behavior. I thought that we warned while inferring meta (by calling the function). I agree with your proposal.

Yes, it makes sense to me.
I was thinking about some changes in blockwise.py#L246 :
        from dask.array.core import is_scalar_for_elemwise
        if all([a._meta is args[0]._meta for a in args[::2] if not is_scalar_for_elemwise(a) ]):
            meta = args[0]._meta
        else:
            warnings.warn("args have different meta, you should provide meta= explicitly if dtype is provided")

I had to import is_scalar_for_elemwise to check if args is scalar.  Perhaps that to check for _meta attr should be enough ?

I don't think using is to compare objects is gonna work, as their _meta may be similar or even equal, but not the same instance in most cases. I think what we want is something like the following:
    if meta is None:
        from .utils import compute_meta

        if dtype is not None:
            if all([type(a._meta) is type(args[0]._meta) for a in args[::2]]):
                meta = args[0]._meta
            else:
                warnings.warn("args have different meta, you should provide meta= explicitly "
                              "if dtype is provided to prevent meta computation on empty arrays")
                meta = compute_meta(func, dtype, *args[::2], **kwargs)

I've got some cases where args have no _meta, nor is_scalar_for_elemwise ie from code like:
import numpy as np
import xarray as xr

arr=xr.DataArray(np.random.randn(10), dims=("x"), coords={"x": np.arange(10)}).chunk({'x':5})
res=arr.data.map_blocks(lambda d,func,axe:func(axe),lambda axe:axe+0.5,arr.x,dtype='f8')

(one of the args is a function)
So my proposal is:
    if meta is None:
        if dtype is not None:
            uniq_meta = set([type(a._meta) for a in args[::2] if isinstance(a, Array)])
            if len(uniq_meta) == 1:
                meta = list(uniq_meta)[0]
            else:
                warnings.warn("args have different meta, you should provide meta= explicitly "
                              "if dtype is provided to prevent meta computation on empty arrays")
        if meta is None:
            from .utils import compute_meta

            meta = compute_meta(func, dtype, *args[::2], **kwargs)

Or, if having a function in args must raise a meta warning:
    if meta is None:
        if dtype is not None:
            from dask.array.core import is_scalar_for_elemwise
            try:
                uniq_meta = set([type(a._meta) for a in args[::2] if not is_scalar_for_elemwise(a)])
            except AttributeError:
                uniq_meta = []
            if len(uniq_meta) == 1:
                meta = list(uniq_meta)[0]
            else:
                warnings.warn("args have different meta, you should provide meta= explicitly "
                              "if dtype is provided to prevent meta computation on empty arrays")
        if meta is None:
            from .utils import compute_meta

            meta = compute_meta(func, dtype, *args[::2], **kwargs)

Could you try using https://github.com/dask/dask/blob/8a699223982ce8425f59f048d0163090b4a81193/dask/array/utils.py#L31 ?
The code I posted before would look something like:
    if meta is None:
        from .utils import compute_meta

        if dtype is not None:
            if all([type(meta_from_array(a)) is type(meta_from_array(args[0])) for a in args[::2]]):
                meta = meta_from_array(args[0]._meta)
            else:
                warnings.warn("args have different meta, you should provide meta= explicitly "
                              "if dtype is provided to prevent meta computation on empty arrays")
                meta = compute_meta(func, dtype, *args[::2], **kwargs)

I confirm that code before using meta_from_array works as expected in the cases I've tested.

I confirm that code before using meta_from_array works as expected in the cases I've tested.

Sorry, I'm having difficulty with interpreting your sentence accurately. Are you saying that:

The previous code but now with meta_from_array -- which is the code in https://github.com/dask/dask/issues/6690#issuecomment-703910822 -- works as expected; or
The code you wrote before my suggestion to use meta_from_array -- code in ttps://github.com/dask/dask/issues/6690#issuecomment-703858616d -- is working?

Sorry.
I was talking about your solution (1) at  https://github.com/dask/dask/issues/6690#issuecomment-703910822
My solution (2) at https://github.com/dask/dask/issues/6690#issuecomment-703858616 using set and meta_from_array just change the if condition:
if len(set([type(meta_from_array(a)) for a in args[::2]])) == 1:

But why are you using
meta = meta_from_array(args[0]._meta)

?
may be this can be replaced by:
meta = meta_from_array(args[0])

?
or perhaps with:
meta = meta_from_array(args[0]).astype(dtype)

?
Because I've seen that the following code:
da.arange(10,chunks=5).map_blocks(lambda x:(x+0.5).astype('f4'),dtype='f4')

compute a meta like array([], dtype=int64), and I'm confused about the dtype that dosen't match the one I gave.

If everything works, I would prefer my solution with meta_from_array to remain consistent with the rest of Dask, where we frequently use it to handle meta rather than creating custom code.
I'm sorry, it was a mistake to suggest meta_from_array(args[0]._meta), what I meant to suggest is just meta_from_array(args[0]), as you noticed.
Regarding the dtype, I didn't suggest it because I think map_blocks should adjust meta's dtype properly when it runs, but I may be mistaken on this one. Since I'm not totally certain about it, we can definitely ensure it's set now and adjust that later if necessary, I suggest we do it with meta_from_array(args[0], dtype=dtype), because astype is done internally https://github.com/dask/dask/blob/34fd6261bfc58f748c2db068dc74482d391ce130/dask/array/utils.py#L103-L104

I think that we need to enforce meta dtype (as you proposed with meta_from_array(args[0], dtype=dtype), because without, the resulting dataarray have not the correct dtype:
da.arange(10,chunks=5).map_blocks(lambda x: (x+0.5).astype('f4'), dtype='f4')
Out[1]: dask.array<lambda, shape=(10,), dtype=int64, chunksize=(5,), chunktype=numpy.ndarray>

With meta_from_array(args[0], dtype=dtype), it's ok, but perhaps that we could add a warning filter in https://github.com/dask/dask/blob/34fd6261bfc58f748c2db068dc74482d391ce130/dask/array/utils.py#L103-L104
Because there is a useless warning message with complex numbers:
da.arange(10,chunks=5).astype('c16').map_blocks(lambda x: np.abs(x).astype('f4'), dtype='f4')
/home/oarcher/git/dask/dask/array/utils.py:104: ComplexWarning: Casting complex values to real discards the imaginary part
  meta = meta.astype(dtype)
Out[1]: dask.array<lambda, shape=(10,), dtype=float32, chunksize=(5,), chunktype=numpy.ndarray>

That's not a useless message, in your lambda np.abs is actually casting to float64, that's why you don't get the same warning there when you do astype('f4'). However, this is the downside of not doing the full path with compute_meta, in compute_meta we actually execute the np.abs on meta to ensure it gets also the correct dtype. In the particular case above, we would be fine in just filtering out ComplexWarning, but I don't know how many more casts could raise some warnings when casting, and I believe we don't want to treat all possible cases in there. @TomAugspurger any suggestions/preferences on how we should address this sort of warning?

We're actually filtering that via NumPy already in https://github.com/dask/dask/blob/8a699223982ce8425f59f048d0163090b4a81193/dask/array/utils.py#L110-L111
I forgot this existed, but simply adding those two lines before meta = meta_from_array(args[0], dtype=dtype) seems to resolve the issue. I'm not certain this is the best solution overall (including for compute_meta), but we already have a precedent for that, so let's use it to resolve this issue and iterate in the future if we find problems with it later.

I was running Dask's test suite and with just master I see 66 fails, I didn't go through all of them to see if something is wrong or missing in my environment, but that's definitely more than 0 failures which is what I expected. Then I ran the suite with the following changes:
    if meta is None:
        from .utils import compute_meta, meta_from_array

        if dtype is not None:
            if all([type(meta_from_array(a)) is type(meta_from_array(args[0])) for a in args[::2]]):
                with np.errstate(all="ignore"), warnings.catch_warnings():
                    warnings.simplefilter("ignore", category=RuntimeWarning)
                    meta = meta_from_array(args[0], dtype=dtype)
            else:
                warnings.warn("args have different meta, you should provide meta= explicitly "
                              "if dtype is provided to prevent meta computation on empty arrays")
                meta = compute_meta(func, dtype, *args[::2], **kwargs)

With the changes above I see 351 failed tests, or a total of 255 new tests failing. Removing the warning, I see 205 tests failing. Those changes are changing some of the existing expected behavior in Dask, I didn't have time to look into that in more detail yet. It's also important to note that only because of the warning we see almost 150 tests failing, this seems like it's going to turn into a major hassle for existing user code, thus I would suggest we document the behavior but don't print warnings.
That still leaves us with another about 150 failing tests to tackle, so I think this is going to take a while.
Finally, just to be sure we weren't doing something wrong, I also ran the code from https://github.com/dask/dask/issues/6690#issuecomment-703858616, and with that I see almost 500 new failing tests. It seems that the solution I suggested in above in this comment is better, but we'll have to fix it further. I'm not sure how soon I'll be able to look into all that.

ouch ! I'm afraid I wont be able to help for those sides effects. But, regarding the reason of opening this issue, perhaps that we can fallback to option 1 in https://github.com/dask/dask/issues/6690#issuecomment-701481444 :

Just update the docs. Instruct users to specify both dtype and meta

but both ? I think just meta is ok:
import dask.array as da
import numpy as np

def func(block):
    print("func called")
    return np.abs(block).astype('f4')

data = da.arange(10,chunks=5).astype('c16')

# incorrect, func is called
In[1]: data.map_blocks(func, dtype='f4')

func called
Out[1]: dask.array<func, shape=(10,), dtype=float32, chunksize=(5,), chunktype=numpy.ndarray>

# correct, func is not called, and output dtype is ok
In[2]: data.map_blocks(func, meta=np.array([],dtype='f4'))
Out[2]: dask.array<func, shape=(10,), dtype=float32, chunksize=(5,), chunktype=numpy.ndarray>

# specifying both dtype and meta is confusing (dtype not used)
In[3]: data.map_blocks(func, dtype='f8', meta=np.array([],dtype='f4'))
Out[3]: dask.array<func, shape=(10,), dtype=float32, chunksize=(5,), chunktype=numpy.ndarray>

So from my user point of vue, the doc should promote the use of meta instead of dtype to avoid function call. There is no needs to use dtype keyword, as the dtype can be specified in meta (probably linked to https://github.com/dask/dask/issues/5007 ?)

My only light objection to specifying meta is that it's slightly more
annoying to type, especially if you're trying to get the dimensionality of
the array correct.
Dask DataFrame allows a shorthand notation like
meta=("name", "int64")

as a shorthand for
meta = pd.Series(np.array([], dtype="int64"), name="name")

We could do something similar for array, something like
meta=(ndarray_type, ndim, dtype).
On Thu, Oct 8, 2020 at 9:41 AM Olivier ARCHER<EMAIL_ADDRESS>wrote:

ouch ! I'm afraid I wont be able to help for those sides effects. But,
regarding the reason of opening this issue, perhaps that we can fallback to
option 1 in #6690 (comment)
https://github.com/dask/dask/issues/6690#issuecomment-701481444 :

Just update the docs. Instruct users to specify both dtype and meta

but both ? I think just meta is ok:
import dask.array as daimport numpy as np
def func(block):
print("func called")
return np.abs(block).astype('f4')
data = da.arange(10,chunks=5).astype('c16')
incorrect, func is calledIn[1]: data.map_blocks(func, dtype='f4')
func calledOut[1]: dask.array<func, shape=(10,), dtype=float32, chunksize=(5,), chunktype=numpy.ndarray>
correct, func is not called, and output dtype is okIn[2]: data.map_blocks(func, meta=np.array([],dtype='f4'))Out[2]: dask.array<func, shape=(10,), dtype=float32, chunksize=(5,), chunktype=numpy.ndarray>
specifying both dtype and meta is confusing (dtype not used)In[3]: data.map_blocks(func, dtype='f8', meta=np.array([],dtype='f4'))Out[3]: dask.array<func, shape=(10,), dtype=float32, chunksize=(5,), chunktype=numpy.ndarray>
So from my user point of vue, the doc should promote the use of meta
instead of dtype to avoid function call. There is no needs to use dtype
keyword, as the dtype can be specified in meta (probably linked to #5007
https://github.com/dask/dask/issues/5007 ?)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/dask/dask/issues/6690#issuecomment-705617785, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKAOITXJEGQAWKJ3FEU27LSJXFSZANCNFSM4R7HUC4A
.

Yes, I think we should definitely update the docs for now. TBH, I'm not sure how we can improve that further at this point.

We could do something similar for array, something like meta=(ndarray_type, ndim, dtype).

You can use meta=meta_from_array(ndarray_type, ndim, dtype), does that work for you?

Yes, using meta=meta_from_array(ndarray_type, ndim, dtype) seems to work as expected:
import dask.array as da
from dask.array.utils import meta_from_array
import numpy as np

def func(block):
    print("func called")
    return np.abs(block).astype('f4')

data = da.arange(10,chunks=5).astype('c16')

data.map_blocks(func, meta=meta_from_array(np.ndarray,1,dtype='f4'))

Out[1]: dask.array<func, shape=(10,), dtype=float32, chunksize=(5,), chunktype=numpy.ndarray>

Just FYI, I opened https://github.com/dask/dask/pull/6763 to document meta, let me know if I missed something.

It seems https://github.com/dask/dask/pull/6763 closes this issue. @oarcher  feel free to re-open if that's not the case


[20.09] firefox: 82.0.3 -> 83.0

Motivation for this change
Backport of #104051
Things done

[ ] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[ ] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

Closing pending new PR with pipewire fixes. Re #104051

@stigtsp / @edolstra did you actually compile/test this? It also requires an NSS update which I haven't seen anywhere yet.

I did not (yet), hence marking as draft