[NetApp] netapp microsoft.net app 2023 05 01

ARM (Control Plane) API Specification Update Pull Request
PR review workflow diagram
Please understand this diagram before proceeding. It explains how to get your PR approved & merged.

[1] ARM review queue (for merge queues, see [4])
The PRs are processed by time opened, ascending. Your PR may show up on 2nd or later page.
If you addressed Step 1 from the diagram and your PR is not showing up in the queue, ensure the label ARMChangesRequested
is removed from your PR. This should cause the label WaitForARMFeedback to be added.
[2] https://aka.ms/azsdk/support/specreview-channel
[3] List of SDK breaking changes approvers in pinned Teams announcement
[4] public repo merge queue, private repo merge queue (for ARM review queue, [1])
If you need further help with anything, see Getting help section below.
Purpose of this PR
What's the purpose of this PR? Check all that apply. This is mandatory!

[x] New API version. (Such PR should have been generated with OpenAPI Hub, per this wiki doc.)
[ ] Update existing version for a new feature. (This is applicable only when you are revising a private preview API version.)
[ ] Update existing version to fix swagger quality issues in S360.
[ ] Other, please clarify:

edit this with your clarification

Due diligence checklist
To merge this PR, you must go through the following checklist and confirm you understood
and followed the instructions by checking all the boxes:

[x] I confirm this PR is modifying Azure Resource Manager (ARM) related specifications, and not data plane related specifications.
[x] I have reviewed following Resource Provider guidelines, including
ARM resource provider contract and
REST guidelines (estimated time: 4 hours).
I understand this is required before I can proceed to Step 2, "ARM Review", for this PR.

Breaking changes review (Step 1)

If the automation determines you have breaking changes, i.e. Step 1 from the diagram applies to you,
you must follow the breaking changes process.
IMPORTANT This applies even if:

The tool fails while it shouldn't, e.g. due to runtime exception, or incorrect detection of breaking changes.
You believe there is no need for you to request breaking change approval, for any reason.
Such claims must be reviewed, and the process is the same.

ARM API changes review (Step 2)

If this PR is in purview of ARM review then automation will add the ARMReview label.
If you want to force ARM review, add the label yourself.
Proceed according to the diagram at the top of this comment.

Getting help

For general PR approval workflow, see the diagram at the top of this comment.
For guidance on fixing this PR CI check failures, see the hyperlinks provided in given failure
and https://aka.ms/ci-fix.
If the help provided by the previous points is not enough, post to https://aka.ms/azsdk/support/specreview-channel and link to this PR.

Breaking changes previously reviewed and approved in https://github.com/Azure/azure-rest-api-specs-pr/pull/8331

/azp run

Please check and fix the Avocado errors.

Please check and fix the Avocado errors.
@ms-henglu Those errors are related to the approved breaking changes

@audunn the Avocado check is no longer required to merge a PR.  You can confirm this by observing the check Automated merging requirements met no longer mentions Avocado and by lack of the Required label beside Avocado in the list of failing checks at the bottom of the PR. Please proceed as explained in the Next Steps to Merge comment and the PR description diagram. Thanks!

"/subscriptions/{subscriptionId}/providers/Microsoft.NetApp/locations/{location}/queryNetworkSiblingSet": {

Can these two POST calls be modelled as GET and PUT calls?

Refers to: specification/netapp/resource-manager/Microsoft.NetApp/stable/2023-05-01/netapp.json:332 in 4569115. [](commit_id = 45691155e65c67e45eda841b975aab68077d0bf5, deletion_comment = False)

  "title": "Subnet resource Id",

consider formatting the property as an arm-id. https://github.com/Azure/autorest/blob/main/docs/extensions/readme.md#x-ms-arm-id-details

Refers to: specification/netapp/resource-manager/Microsoft.NetApp/stable/2023-05-01/netapp.json:7388 in 4569115. [](commit_id = 45691155e65c67e45eda841b975aab68077d0bf5, deletion_comment = False)

"/subscriptions/{subscriptionId}/providers/Microsoft.NetApp/locations/{location}/queryNetworkSiblingSet": {

Can these two POST calls be modelled as GET and PUT calls?
Refers to: specification/netapp/resource-manager/Microsoft.NetApp/stable/2023-05-01/netapp.json:332 in 4569115. [](commit_id = 4569115, deletion_comment = False)

Not realy this is not creating any resoruces, it is querying the backend for specific data this cannot be done within the GET latency requrements.

"volumeResourceIds": {

Looks like this could also benefit from formatting as arm-id for stronger typing and better consistency.

Refers to: specification/netapp/resource-manager/Microsoft.NetApp/stable/2023-05-01/netapp.json:7379 in 03c360f. [](commit_id = 03c360fb5232c6f48cbb239b0e7d6b71e7b83cbe, deletion_comment = False)

Signed off for ARM with comments. Please take a look and consider making the suggested change before merge.

@mentat9 out of curiosity if we were to add arm-id to an existing property for consitency sake,  would that be a breaking change, do you know?

@mentat9 , @sjanamma out of curiosity if we were to add arm-id to an existing property for consitency sake, would that be a breaking change, do you know?

@audunn - Looks like the automation answered your question by adding the BreakingChangeReviewRequired label. Note I didn't require that change for ARM signoff, but to merge, you will need to either revert it or get breaking change approval. I imagine it should pass breaking change review easily since it doesn't represent a change from your backend (IIUC).

arm-id

@mentat9 That seems strange, perhaps a false positive here, as we added arm-id to a new property introduced in this api-version not to an existing one.  We need to look into why it flags

Prettier fails , does not fail locally something with the pipeline
prettier -c specification/netapp/resource-manager/Microsoft.NetApp/stable/2023-05-01/examples/Volumes_Update.json
[error] Cannot find module 'prettier/plugins/estree'
[error] Require stack:
[error] - /mnt/vss/_work/1/azure-rest-api-specs/eng/scripts/prettier-swagger-plugin.js
[error] -<EMAIL_ADDRESS>[error] -<EMAIL_ADDRESS>

/azp run

/pr RequestMerge


CSV Export filtered data

Expected Behavior
CSV export should export the filtered data.
Current Behavior
CSV export exports all of the data.
Steps to Reproduce (for bugs)

Go to https://codesandbox.io/s/wy2rl1nyzl
Apply any filter
Download CSV
tableDownload.csv contains all data.

Your Environment
This happens in the CodeSandbox demo from README.md
There is a resolved issue #207 about this but it seems this has been broken again during refactoring.

Looks like there is a PR already #440 🤦♂


proposal: upvote functionality

#106 is missing upvote functionality. This can be done by having the ▲ be a button that sends a fetch request to /api/vote once clicked, where a table row will be created in a votes table. The votes table will have two columns, user_id and item_id. The rest is self-explanatory.
The status of this button will correlate to whether there is a match for both the logged-in user and the current item ID in the votes table.
The main feed should also sort by amount of votes, from most to least, and display each item's score.

Completed in #154.


FastClasspathScanner should support Java EA Version String

Currently, FastClasspathScanner 3 doesn't seem to work with EA versions of Java simply because it tries to parse the version String as number (see Caused by: java.lang.NumberFormatException: For input string: "11-ea"). This is unfortunate, since it prevents users from doing testing against EA versions. Since Java has a much more frequent release cycle testing with EA releases is super important. Are you aware of the issue? Thanks!
Caused by: java.lang.RuntimeException: java.lang.ExceptionInInitializerError
        at io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1640)
        at io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1674)
        at io.github.lukehutch.fastclasspathscanner.FastClasspathScanner.scan(FastClasspathScanner.java:1700)
        at eu.mihosoft.vmf.VMF.listClassesInPackage(VMF.java:128)
        at eu.mihosoft.vmf.VMF.generate(VMF.java:114)
        at eu.mihosoft.vmf.VMF$generate.call(Unknown Source)
        at eu.mihosoft.vmf.gradle.plugin.VMFPlugin$_apply_closure5$_closure12.doCall(VMFPlugin.groovy:110)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:732)
        at org.gradle.api.internal.AbstractTask$ClosureTaskAction.execute(AbstractTask.java:705)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$1.run(ExecuteActionsTaskExecuter.java:131)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:317)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor$RunnableBuildOperationWorker.execute(DefaultBuildOperationExecutor.java:309)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.execute(DefaultBuildOperationExecutor.java:185)
        at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:97)
        at org.gradle.internal.operations.DelegatingBuildOperationExecutor.run(DelegatingBuildOperationExecutor.java:31)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:120)
        at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:99)
        ... 105 more
Caused by: java.lang.ExceptionInInitializerError
        at io.github.lukehutch.fastclasspathscanner.scanner.ModuleRef.findModuleRefs(ModuleRef.java:423)
        at io.github.lukehutch.fastclasspathscanner.scanner.ClassLoaderAndModuleFinder.<init>(ClassLoaderAndModuleFinder.java:154)
        at io.github.lukehutch.fastclasspathscanner.scanner.ClasspathFinder.<init>(ClasspathFinder.java:190)
        at io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:214)
        at io.github.lukehutch.fastclasspathscanner.scanner.Scanner.call(Scanner.java:55)
Caused by: java.lang.NumberFormatException: For input string: "11-ea"
        at io.github.lukehutch.fastclasspathscanner.utils.ReflectionUtils.<clinit>(ReflectionUtils.java:313)

Seems to be fixed in 3.1.12. Sorry for the noise.

@miho Yes, this was reported once before, and fixed, but thanks for reporting!
Just as an unrelated heads-up, I am mostly finished with a huge refactoring and API cleanup effort, which will be released as v4 in the next couple of days, so check back soon for a much improved (and different) API.


Provide CA-specific guidance on how to link genomic data with CalREDIE investigations

Thanks @mtcaton for this awesome idea! :)

On reflection, closing this issue as I think this is an incredibly important resource, but probably lives alongside the Gen Epi playbook, rather than galago?


[NOD-542] Remove redundant flags from Kasparov migrate call

Rebuild after update in master

Rebuild after update in master


[web] Turn on the flag for CanvasKit Chromium

Once we are ready to enable CanvasKit Chromium for users, we need to turn on this flag:
https://github.com/flutter/engine/blob/832298bdd707ceabf6641d67d0550d231ac0acb7/lib/web_ui/lib/src/engine/browser_detection.dart#L270-L273

Currently blocked on https://github.com/flutter/engine/pull/40154


rockpro64-0.6.51 crashes

0.6.51-log.txt

And that one works for me (though not every time).

Sometimes it crashes when you boot, sometimes not. When it runs it's very stable for me.

Seems to be fixed in 0.6.53


Cache bitstreams

Synthesis and PAR are slow, rerunning them on every invocation is wasteful, and explicit --no-build is awful.
Needs extra care so that it works on:

[x] Linux
[x] macOS
[x] Windows

Instead of caching files in some system location, bitstreams are now cached in device memory (volatile and non-volatile) after 48a130ff. This is far more portable and far less likely to result in stale caches leading to confusing results (especially if you don't flash EEPROM) while still eliminating most rebuilds (unless you switch between two applets continuously).
We can revisit this later, but this works for now.

We decided to cache bitstreams after all, which becomes possible to do safely after #353 is merged.


Bugging through secure windoor

Description
You can go through secure windoor on thhe new map NTED Gate Station PR-370
Reproduction

jump on the table like this in that exact spot and try to mess wiith wiress and get  shocked, you will get pushed in between table and window and the games letss youu passs thinkiing you're inside the room when you fall down.
Screenshots

Additional context
https://imgur.com/a/Hnq2RRN

I saw someone with the name ron ron doing it by mistake :))


Improve documentation

Move and duplicate note about running under multiple Python versions to the start of each command's section.
Add note about using --upgrade and --upgrade-package together following #831.
Document --output-file.

Changelog-friendly one-liner: n/a
Contributor checklist

[n/a] Provided the tests for the changes.
[n/a] Requested a review from another contributor.
[n/a] Gave a clear one-line description in the PR (that the maintainers can add to CHANGELOG.md on release).
[n/a] Assign the PR to an existing or new milestone for the target version (following Semantic Versioning).

@atugushev would you mind checking this over? :)

Thanks!


pip install from pypi

Hi,
First of all, cheers. This seems like a great tool, it should get more traction.
I was wondering - It seems you can clone and pip install from requirements.txt.
Would it be feasible to make it into a proper package? This makes deploying it much easier, among another benefits.
Thanks,
Eli

Hi @h5rdly ,
Thanks for reaching us.
IIUC you would like to use something like pip install omnidb to install all OmniDB required libraries. Is that what you want?
Regards.

Making omnidb be installable from pip would be sweet.  In my opinion id
also only try and support linux and python3.  By being installabke from PIP
having a doxker inage would be easy to maintain
On Tue, Oct 20, 2020, 2:52 PM Israel<EMAIL_ADDRESS>wrote:

Hi @h5rdly https://github.com/h5rdly ,
Thanks for reaching us.
IIUC you would like to use something like pip install omnidb to install
all OmniDB required libraries. Is that what you want?
Regards.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/OmniDB/OmniDB/issues/1147#issuecomment-713069266, or
unsubscribe
https://github.com/notifications/unsubscribe-auth/AAMWOHWRFDVDWF2MVAF4D33SLXMABANCNFSM4PCFARGQ
.

Cool, thanks for clarifying. We'll discuss about it and let you know on any news.


Better handling for /

WAS currently responds with Hello World JSON at /.
When the WAS web ui is served via FastAPI/WAS we should respond with something more meaningful for users accessing WAS with a browser.
We should serve up simple nginx/apache style default HTML that at least lets the user know they have correctly accessed their WAS installation. For flexibility and future use it should include links to docs at heywillow.io, links to the admin interface, and potentially a reference to the FastAPI autogenerated documentation for the WAS API.

wasng performs a redirect from / to /admin


Fix a bug that scrape.Session.follow doesn't work with compiled regexp.

Also fixed/improved some method docs.

LGTM. Merged.


replace deprecated tns livesync with tns run in start.android script

Running npm run start.android as per the docs currently results in a build failure because the tns livesync command has been deprecated. Replacing it with tns run android fixes the problem

I'll take a look at ios as well


Clean up D3 submodule imports

I noticed one of the last commits by @tomalrussell was cleaning up the d3 imports a bit. This has been annoying how d3 needs to be imported in projects relying in ES6 modules in quite a different manner than it used to work back in the days of global objects. Especially when you need to use functions from more than two submodules in one file.
Recently I came up with this approach on a different project:
[in a file such as /lib/d3.ts]:
import * as d3Array from 'd3-array';
import * as d3Format from 'd3-format';
import * as d3Interpolate from 'd3-interpolate';
import * as d3Scale from 'd3-scale';
import * as d3ScaleChromatic from 'd3-scale-chromatic';

export const d3 = {
  ...d3Scale,
  ...d3ScaleChromatic,
  ...d3Array,
  ...d3Interpolate,
  ...d3Format,
};

// eslint-disable-next-line @typescript-eslint/no-namespace
export namespace D3 {
  export import scale = d3Scale;
  export import scaleChromatic = d3ScaleChromatic;
  export import array = d3Array;
  export import interpolate = d3Interpolate;
  export import format = d3Format;
}

The d3 object contains all the exports from all the installed submodules. They need to be manually destructured just once in this central file. Later, it's enough to just import d3 from this file, and because it's a named export, it works well with IntelliSense etc. Usage is:
import { d3 } from '@/lib/d3';

const scale = d3.scaleLinear(/*...*/);

The D3 namespace helps with the fact that it's not possible to destructure and re-export types. Usage is:
import { type D3 } from '@/lib/d3';

let scale: D3.scale.ScaleLinear<number, number> = undefined;

/* ... */

I won't change this for now, but something to consider. I've been quite happy with the DX this provides on other projects.

This was the commit in question: 3bc0da730f6d0bfa351934300e1eff85798c1c22
The proposal sounds reasonable to me, the hoops to jump through type checking and submodule imports are not awesome right now.
cc @shiarella for any comments?


Implement SE-0075: CanImport

This implementation required a compromise between parser
performance and AST structuring.  On the one hand, Parse
must be fast in order to keep things in the IDE zippy, on
the other we must hit the disk to properly resolve 'canImport'
conditions and inject members of the active clause into the AST.
Additionally, a Parse-only pass may not provide platform-specific
information to the compiler invocation and so may mistakenly
activate or de-activate branches in the if-configuration decl.
The compromise is to perform condition evaluation only when
continuing on to semantic analysis.  This keeps the parser quick
and avoids the odd unpacking that parse does for active conditions
while still retaining the ability to see through to an active
condition when we know we're moving on to a more expensive phase like
semantic analysis anyways.
Resolves SR-1560 and any associated shadowing oddities from the first go around.

@swift-ci please test

Longer-term answers to this would be to push condition resolution further down into the stack.  But we currently don't have a strong phase separation between name binding and parse.

Build failed
Swift Test OS X Platform
Git Sha - 3e41c5602ff33c33809783c6e7b2a8df8b78ffe6

@harlanhaskins Does not doing condition resolution in parse-only passes affect libSyntax at all?

@swift-ci test

@swift-ci test

@benlangmuir So then, what's the best way to detect that in a parse-only pass?

@CodaFi Could we rename yourParseOnly bit to something like ShouldEvaluateIfConfigConditions and set it explicitly in the rename code?

I will add a flag to performParseOnly as a stopgap, but we have to plan for a future where evaluation occurs in a later phase.

@swift-ci please smoke test

@swift-ci please smoke test

@CodaFi

@benlangmuir I originally wanted to do this in name binding but now I think making the configurations a kind of DeclContext and teaching lookup about how to properly find these is the right way to model the problem.
If Syntactic Rename needs this, and the cost of hitting the disk isn't a problem, would it be possible to use the semantic tree instead?  Evaluating conditions in the AST is a bona-fide semantic operation that doesn't belong in Parse.

An option might be to have this notion of the "name bound tree" for the point at which the AST is well-formed syntactically and has gone through condition resolution and name binding but has not yet been typechecked.

@CodaFi why do we need to conflate if-config condition evaluation with name binding?  We don't need name-binding to evaluate the conditions, right?  It seems like what we want for syntactic rename is to walk the syntax tree but evaluate and track the if-config context as we go.

Because condition resolution can introduce arbitrary names into scopes. That requires re-binding declrefs that are currently being eagerly bound by Parse.  Currently, that's how Syntactic Rename is even finding these names: Parse is hoisting the active set of declarations and statements into the right scope and then binding them later on which is strange because it means our parser has its own understanding of scope.
My idea, post ASTScope, is to scrap all of that and teach lookup to walk through these conditions.

Or if we start from a distinguished syntactic tree, whatever the reverse of the LegacyASTTransformer is could resolve these conditions

@CodaFi syntactic rename shouldn't need name binding in theory.  It gets its list of locations from the indexer not by looking at the AST.  We only parse so that we can figure out argument labels, determine active-vs-inactive, etc.  If parsing no longer puts active code into scopes or no longer binds names itself then I think we should adapt to that rather than require name binding.  CC @nathawes in case I'm missing something.

@swift-ci please test and merge

@swift-ci please test and merge

Failures are definitely unrelated.
@swift-ci please smoke test and merge

@swift-ci please smoke test and merge

Mentioning this as rdar://problem/27382987 to hopefully help Apple's automated systems to track the PR.


Loading large IFC file crashes browser

Hey,
super cool project! I was looking around for a BIM/IFC viewer and found you through google.
I, maybe ambitiously, loaded the famous 7 story hospital file:
Famous hospital IFC file
It showed up somewhere high "in the sky" of the model, but panning and zooming quickly crashed the browser and was really slow.
Can the project already handle these kind of files? Will it be able to handle them in a later stage?

Hey, thanks! We are working to optimize the geometry, so the performance should get better this week. Regarding the position of the model, I have inspected it and it looks like the model is 165 m above the 0 level. Can you create a issue in the web-ifc repo to solve this?

Hey,
Thanks for your comment. As far as I understand, the IFC coordination is meant to also place in the world. So I assume the building is normally elevated 165m above sea level?
Might also that I am misunderstanding.

Yes, that's correct! I didn't want to imply that the IFC is wrong. If you create an issue in the abovementioned repository, we will be able to track that and implement a solution for cases in which IfcSite contemplates the elevation of the building.


'Invalid MEX-file' error

I'm using precompiled Matlab Libraries, an error occurred when I ran test example:
Invalid MEX-file '/home/yangt/workspace/matlabProjects/snopt-matlab-2.5.0/matlab/snoptmex.mexa64':
libgfortran.so.4: cannot open shared object file: No such file or directory.
Error in snscreen (line 18)
  snoptmex( screenon );
Error in runNPexamples (line 6)
snscreen on

My system is Ubuntu 16.04 and MATLAB version is 2016a. Could you give me some advise how to solve this problem? Thanks for your reading.

You're missing the gfortran library. Install gfortran (sudo apt-get install gfortran) and it should solve the problem.

thanks for your hint, problem has been solved!


Add plural.sh deployment example

Supplanted by https://github.com/silverton-io/honeypot/issues/275


Bug registering name

I got this error when trying to register a .chain name:

The name first disappeared from the wallet, and then appeared there.

https://github.com/aeternity/superhero-wallet/issues/1143#issuecomment-868325260

This issue wasn't fixed it is still happening, we are planning to work on it in the near future.


Support for building on x86_64-darwin

BTW: The failing build is due to hlint, which I fixed in another PR, but is not yet merged.

Building with these changes on x86_64-darwin currently produces the following error:
$ nix build --print-build-logs
error: output '/nix/store/06xz3q2hvn3m7wh3bn4xfiwyrwrd2ybg-stdenv-darwin' is not allowed to refer to the following paths:
         /nix/store/fzy212s65vik6wlyxv02lmhc22wp0zms-llvm-14.0.1-lib
         /nix/store/v9qbhh73chx2xz2ddjv23plxwbky9wj0-llvm-14.0.1
error: 1 dependencies of derivation '/nix/store/ar3z16dmzcfnj347ds8wgh04dixz2ygm-cabal2nix-2.18.0.drv' failed to build
error: 1 dependencies of derivation '/nix/store/zy86g8w4mw518kljw2b3kjl2bmr3gbfs-cabal2nix-eclair-lang.drv' failed to build
(use '--show-trace' to show detailed location information)

The contents of /nix/store/zy86g8w4mw518kljw2b3kjl2bmr3gbfs-cabal2nix-eclair-lang.drv are as follows:
Contents of the derivation

Derivation
  { outputs =
      fromList
        [ ( "out"
          , DerivationOutput
              { path =
                  "/nix/store/rcrhqlfbx28751izs3ikima7hwr3bydb-cabal2nix-eclair-lang"
              , hashAlgo = ""
              , hash = ""
              }
          )
        ]
  , inputDrvs =
      fromList
        [ ( "/nix/store/0w33zcq6a34pakvqaxyw88b5lpzkvb8s-stdenv-darwin.drv"
          , fromList [ "out" ]
          )
        , ( "/nix/store/ar3z16dmzcfnj347ds8wgh04dixz2ygm-cabal2nix-2.18.0.drv"
          , fromList [ "out" ]
          )
        , ( "/nix/store/n00038lvz7jip14aabwsb3l0lk79yz5z-bash-5.1-p16.drv"
          , fromList [ "out" ]
          )
        ]
  , inputSrcs =
      fromList
        [ "/nix/store/9krlzvny65gdc8s7kpb6lkx8cd02c25b-default-builder.sh"
        , "/nix/store/vmz9xqv6h3fqpzybcalp1wi9pgrlr7z9-source"
        ]
  , platform = "x86_64-darwin"
  , builder =
      "/nix/store/1kkhc1nyadqkb0c63dpzrsp8pb0bwj3l-bash-5.1-p16/bin/bash"
  , args =
      [ "-e"
      , "/nix/store/9krlzvny65gdc8s7kpb6lkx8cd02c25b-default-builder.sh"
      ]
  , env =
      fromList
        [ ( "LANG" , "en_US.UTF-8" )
        , ( "LOCALE_ARCHIVE" , "" )
        , ( "__darwinAllowLocalNetworking" , "" )
        , ( "__impureHostDeps"
          , "/bin/sh /usr/lib/libSystem.B.dylib /usr/lib/system/libunc.dylib /dev/zero /dev/random /dev/urandom /bin/sh"
          )
        , ( "__propagatedImpureHostDeps" , "" )
        , ( "__propagatedSandboxProfile" , "" )
        , ( "__sandboxProfile" , "" )
        , ( "allowSubstitutes" , "" )
        , ( "buildCommand"
          , "export HOME=\"$TMP\"\nmkdir -p \"$out\"\ncabal2nix --compiler=ghc-9.0.2 --system=x86_64-apple-darwin --sha256= \"/nix/store/vmz9xqv6h3fqpzybcalp1wi9pgrlr7z9-source\"  > \"$out/default.nix\"\n"
          )
        , ( "buildInputs" , "" )
        , ( "builder"
          , "/nix/store/1kkhc1nyadqkb0c63dpzrsp8pb0bwj3l-bash-5.1-p16/bin/bash"
          )
        , ( "configureFlags" , "" )
        , ( "depsBuildBuild" , "" )
        , ( "depsBuildBuildPropagated" , "" )
        , ( "depsBuildTarget" , "" )
        , ( "depsBuildTargetPropagated" , "" )
        , ( "depsHostHost" , "" )
        , ( "depsHostHostPropagated" , "" )
        , ( "depsTargetTarget" , "" )
        , ( "depsTargetTargetPropagated" , "" )
        , ( "doCheck" , "" )
        , ( "doInstallCheck" , "" )
        , ( "name" , "cabal2nix-eclair-lang" )
        , ( "nativeBuildInputs"
          , "/nix/store/nim0xn498zasgmbjzsgw6y9pichyl02s-cabal2nix-2.18.0"
          )
        , ( "out"
          , "/nix/store/rcrhqlfbx28751izs3ikima7hwr3bydb-cabal2nix-eclair-lang"
          )
        , ( "outputs" , "out" )
        , ( "passAsFile" , "buildCommand" )
        , ( "patches" , "" )
        , ( "preferLocalBuild" , "1" )
        , ( "propagatedBuildInputs" , "" )
        , ( "propagatedNativeBuildInputs" , "" )
        , ( "stdenv"
          , "/nix/store/5xxw3ll3f70y5dywlzv5hrh2xmlzrc2v-stdenv-darwin"
          )
        , ( "strictDeps" , "" )
        , ( "system" , "x86_64-darwin" )
        ]
  }

@kpadmasola You're probably better off closing this PR and adding "x86_64-darwin" again to the updated flake.nix. I tried doing it myself, but got permission denied.

closing this. will open a new PR for darwin support as suggested by @luc-tielen


Micro instances are too small

With micro instances (1GB RAM), it's a bit too easy to run out of memory.

Fixed with merged PR on Aug 11.


feat: pipe syntax with explicit placeholder

Alternative to #3956, using _ to nominate the piped argument, as preferred by @roman-kashitsyn.
TODO:

[x] let-bind argument when necessary to preserve eval order.
[ ] tests

Examples:
[nix-shell:~/motoko/src]$ rlwrap moc --package base $MOTOKO_BASE
Motoko compiler (source 0.8.7-19-ga9dd5b32d-dirty)
> import L = "mo:base/List";
let L : module {...}
> import I = "mo:base/Iter";
let I : module {...}
> import L = "mo:base/List";
let L : module {...}
> import C = "mo:base/Char";
let C : module {...}

> "hello".chars() |> I.map(_, C.toNat32) |> I.toList _ |> L.reverse _;
?(111, ?(108, ?(108, ?(101, ?(104, null))))) : List<Nat32>

> "hello".chars() |> I.map(_, C.toNat32) |> I.toList _ |> L.reverse (_); // handle (_) as _
?(111, ?(108, ?(108, ?(101, ?(104, null))))) : List<Nat32>

> C.toNat32 |> I.map("hello".chars(), _) |> I.toList _ |> L.reverse _; // pipe to second argument
?(111, ?(108, ?(108, ?(101, ?(104, null))))) : List<Nat32>

I love this syntax in the sense of it being a clever and concise generalization. That being said, looking at this through the eyes of a newer Motoko developer, I think the original style #3956 would be more intuitive, and the added opinionation would help keep libraries more consistent with each other.
Either option would be great for different use cases, so I'm just hoping to add an extra opinion to the mix.

I love this syntax in the sense of it being a clever and concise generalization. That being said, looking at this through the eyes of a newer Motoko developer, I think the original style #3956 would be more intuitive, and the added opinionation would help keep libraries more consistent with each other.

Yeah, I'm a little torn. The thing I didn't like about that #3956 is that, though concise, it changes the number of arguments of the operation, which might be its own source of confusion.
"hello".chars() |> I.map(_, C.toNat32)

vs.
"hello".chars() |> I.map(C.toNat32)

Notice how I.map now takes one argument, even though its type (Iter<T>,T->U) -> Iter<U> requires two.
The underscore not only makes the argument clear but also lets you to select a different one than just the first.

Either option would be great for different use cases, so I'm just hoping to add an extra opinion to the mix.

No, that's cool, thanks for the feedback. Let's see if others voice a preference.

A few more examples would be nice to showcase what's supported and the edges of the _ intended usage.

Some other language is going along these lines too https://twitter.com/code_report/status/1657058727239794688

is not legal, because the _ is nested.

Aaah, sorry, that misunderstanding is originating from me then :-O
But is there a hard reason why _ cannot be in a nested position, or is this just a restriction for the PoC?

Some other language is going along these lines too https://twitter.com/code_report/status/1657058727239794688

That links to an interesting survey here:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2672r0.html#to-placehold-or-not-to-placehold

is not legal, because the _ is nested.

Aaah, sorry, that misunderstanding is originating from me then :-O
But is there a hard reason why _ cannot be in a nested position, or is this just a restriction for the PoC? I can easily envision a let-based desugaring that allows nesting and non-linearity.

It was to ensure linearity (as requested by @roman-kashitsyn) without requiring a full linear type system.
A non-linear version allowing nesting should indeed be easy using just 'let', but that wasn't the goal here.

@crusso can this be closed, now that an alternative design got merged?


make dtype readable only

ie. remove attr from Series in order to match Dan::Pandas behaviour

now a method that uses .are


[PoC] Integration tests with Apollo and PostgreSQL database

This PR is a proof-of-concept for a possible way that we could do integration tests with Apollo Server and Prisma, connected with a live PostgreSQL database instance through Docker, as part of #670.
Included are 2 example tests files:

__tests__/integration/lessons.ts - simple query for fetching the lessons and comparing to a snapshot
__tests__/integration/signup.ts - more complex example that goes through the entire user creation process, verifying that the user was actually created on the database

References:

https://www.apollographql.com/docs/apollo-server/testing/testing/
https://www.prisma.io/docs/guides/testing/integration-testing#integration-testing

Closing because nobody has picked this up. Will be picked up with this issue: https://github.com/garageScript/c0d3-app/issues/670


enyo.indexOf should delegate to Array.prototype.indexOf

enyo.indexOf should delegate to Array.prototype.indexOf, whenever possible.
The shim should also match the spec, currently it does not:

missing fromIndex argument
missing sparse array handling
Will match Abstract Equality Comparison , should match as Strict Equality Comparison

Can provide patch

I was hoping we could eliminate this shim altogether, but we still need it for IE8/9. If you can provide a patch that would rock. Thanks Rick.

Cool, will do


NNBD. No error if class with no generative constructor declares not initialized non-nullable instance variable

According to the NNBD specification

It is an error if a mixin declaration or a class declaration with no generative constructors declares an instance variable with a potentially non-nullable type and no initializer expression unless the variable is marked with the late modifier.

But the following test fails
void foo() {}

class C {
  Function f;
  factory C.f() = D;
//        ^^^
// [analyzer] unspecified
// [cfe] unspecified
}

class D implements C {
  Function f = foo;
  D();
}

main() {
  new C.f();
}

There is no expected error in dartanalyzer version 2.8.0-dev.9.0
Expected result: class C declares non-initialized instance variable and has no generative constructor therefore there must be an error

https://dart-review.googlesource.com/c/sdk/+/137282


How to use multer with different config for different API endpoints?

I can't figure out how to use multer (from request parser) with different options on different API endpoints.
Let's say we have following API endpoints:

POST /images
POST /documents

I need different multer options for this two endpoints, how should i use swagger-express-middleware to apply different multer options?

Clairfied title

Closing this issue due to its age. Please re-open it if the issue is still relevant


Usercube connector documentation updated

Usercube is now part of Netwrix and our product offical name is: "Netwrix Usercube"

@bezhan-msft - can you review the proposed changes?
IMPORTANT: When the changes are ready for publication, add a #sign-off comment to signal that the PR is ready for the review team to merge.
#label:"aq-pr-triaged"
@MicrosoftDocs/public-repo-pr-review-team

@nliATusercube please work through the certification portal to submit a new version of your connector that contains those changes. Once those changes are certified, they can be reflected in the public documentation for the connector.

#reassign:ptyx507x


[Fix] Set the missed prefill finish time

This PR fixes a bug which fails to set the prefill finish time and results in metric error.

cc @cyx-6


[RFC] Supporting Armv9 Scalable Matrix Extension (SME) Streaming SVE (SSVE) mode in MLIR / IREE

The Armv9 Scalable Matrix Extension (SME) defines a new "Streaming SVE" (SSVE) execution mode [1].
The purpose of this RFC is to evaluate what is required to support this mode in MLIR / IREE and propose next steps to address this. The focus of this RFC is SSVE only, not full SME support, but this is an important first step towards this.
SSVE is controlled by a processor state bit called PSTATE.SM (see section B1.1 in [1]). From [2]:

At any given point in time, the processor is either in streaming mode (PSTATE.SM==1) or in non-streaming mode (PSTATE.SM==0), also referred to as "normal" mode. There is an instruction called SMSTART to enter streaming mode and an instruction called SMSTOP to return to non-streaming mode.

From [3]:

When changing PSTATE.SM the execution of FP/vector operations may be transferred to another processing element. This has three important implications:

The runtime SVE vector length may change.
The contents of FP/AdvSIMD/SVE registers are zeroed.
The set of allowable instructions changes.

To support this feature there are two key problems to address:

Management of PSTATE.SM.
SVE code-generation.

This RFC is concerned with the former. The latter entails support for scalable vector enablement in MLIR / IREE which is outside of the scope of this RFC, but my colleague Andrzej Warzynski from Arm and Diego Caballero from Google posted an RFC on scalable vectorisation in Linalg last week that's relevant to this and worth a read.
In the LLVM backend PSTATE.SM is managed at the function boundary with function and callsite attributes. These were added in the enablement of the AArch64 SME Arm C Language Extensions (ACLE) [4]. The LLVM AArch64 SME docs [3] go into more detail on this.
To support SSVE in MLIR / IREE we can leverage these existing attributes to manage PSTATE.SM. [5] provides a list of attributes, for the purposes of this RFC only the SSVE attributes are relevant, these are:

aarch64_pstate_sm_enabled
aarch64_pstate_sm_body
aarch64_pstate_sm_compatible

The next section goes into detail for each of them and provides examples.
aarch64_pstate_sm_enabled
Calls to functions with this attribute will be wrapped with smstart sm / smstop sm. For example, take the following LLVM IR:
define void @streaming_callee() #0 {
  ret void
}

define void @normal_caller() {
  call void @streaming_callee()
  ret void
}

attributes #0 = { "aarch64_pstate_sm_enabled" }

Compiled with:
  llc -mtriple=aarch64 -mattr=+sve,+sme

Produces the following asm:
streaming_callee:                       // @streaming_callee
        ret
normal_caller:                          // @normal_caller
        stp     d15, d14, [sp, #-80]!           // 16-byte Folded Spill
        stp     d13, d12, [sp, #16]             // 16-byte Folded Spill
        stp     d11, d10, [sp, #32]             // 16-byte Folded Spill
        stp     d9, d8, [sp, #48]               // 16-byte Folded Spill
        str     x30, [sp, #64]                  // 8-byte Folded Spill
        smstart sm
        bl      streaming_callee
        smstop  sm
        ldp     d9, d8, [sp, #48]               // 16-byte Folded Reload
        ldp     d11, d10, [sp, #32]             // 16-byte Folded Reload
        ldp     d13, d12, [sp, #16]             // 16-byte Folded Reload
        ldr     x30, [sp, #64]                  // 8-byte Folded Reload
        ldp     d15, d14, [sp], #80             // 16-byte Folded Reload
        ret

Streaming mode is enabled before the call to the streaming function and disabled after.
aarch64_pstate_sm_body
The backend will insert smstart sm / smstop sm into the prologue/epilogue for functions with this attribute.
For example, using the IR from the previous example with this attribute:
define void @streaming_callee() #0 {
  ret void
}

define void @normal_caller() {
  call void @streaming_callee()
  ret void
}

attributes #0 = { "aarch64_pstate_sm_body" }

Produces the following asm:
streaming_callee:                       // @streaming_callee
        stp     d15, d14, [sp, #-64]!           // 16-byte Folded Spill
        stp     d13, d12, [sp, #16]             // 16-byte Folded Spill
        stp     d11, d10, [sp, #32]             // 16-byte Folded Spill
        stp     d9, d8, [sp, #48]               // 16-byte Folded Spill
        smstart sm
        smstop  sm
        ldp     d9, d8, [sp, #48]               // 16-byte Folded Reload
        ldp     d11, d10, [sp, #32]             // 16-byte Folded Reload
        ldp     d13, d12, [sp, #16]             // 16-byte Folded Reload
        ldp     d15, d14, [sp], #64             // 16-byte Folded Reload
        ret
normal_caller:                          // @normal_caller
        str     x30, [sp, #-16]!                // 8-byte Folded Spill
        bl      streaming_callee
        ldr     x30, [sp], #16                  // 8-byte Folded Reload
        ret

Notice smstart sm / smstop sm are emitted inside the streaming function, rather than around the call as with the previous attribute.
The ACLE [6] provides more detail on this:

This choice is internal to the function definition. It is not visible to
callers and so it can be changed without affecting the function’s binary
interface. (In other words, it can be changed without requiring all callers
to be recompiled.)
...
This approach can be useful when implementing existing APIs, including when
overriding virtual functions. It allows the use of SME to be an internal
implementation detail.

Since this is an internal attribute that's not visible to the caller, the compiler must disable streaming mode if enabled before calling a locally streaming function.
For example, the following IR:
declare void @locally_streaming_callee() #0

define void @locally_streaming_caller() #0 {
  call void @locally_streaming_callee()
  ret void
}

attributes #0 = { "aarch64_pstate_sm_body" }

Produces this asm:
locally_streaming_caller:               // @locally_streaming_caller
        stp     d15, d14, [sp, #-80]!           // 16-byte Folded Spill
        stp     d13, d12, [sp, #16]             // 16-byte Folded Spill
        stp     d11, d10, [sp, #32]             // 16-byte Folded Spill
        stp     d9, d8, [sp, #48]               // 16-byte Folded Spill
        str     x30, [sp, #64]                  // 8-byte Folded Spill
        smstart sm
        smstop  sm
        bl      locally_streaming_callee
        smstart sm
        smstop  sm
        ldp     d9, d8, [sp, #48]               // 16-byte Folded Reload
        ldp     d11, d10, [sp, #32]             // 16-byte Folded Reload
        ldp     d13, d12, [sp, #16]             // 16-byte Folded Reload
        ldr     x30, [sp, #64]                  // 8-byte Folded Reload
        ldp     d15, d14, [sp], #80             // 16-byte Folded Reload
        ret

The compiler has to emit unnecessary smstart/smstop instructions that in turn cause expensive spills / fills, since the CPU zeroes the FP/vector registers when changing PSTATE.SM.
aarch64_pstate_sm_compatible
Functions with this attribute stick to the streaming subset of SVE and are callable from both normal and streaming-mode. What this means in practice is the function is restricted to set of instructions that are legal in either mode.  This is useful for compatibility in things like vector versions of math.h routines such as tanh.
Initial plan for SSVE support in MLIR/IREE
Streaming mode can be targeted from MLIR at the function boundary by specifying these attributes via the passthrough mechanism [7]. This works today with no changes.
Example MLIR:
// A streaming-mode function.
func.func private @streaming_callee() attributes {passthrough = ["aarch64_pstate_sm_enabled"]}
func.func private @normal_caller() {
  func.call @streaming_callee() : () -> ()
  return
}

Compile:
mlir-opt --convert-func-to-llvm streaming_sve.mlir | mlir-translate --mlir-to-llvmir | llc -mattr=+sve,+sme

normal_caller:
        stp     d15, d14, [sp, #-80]!           // 16-byte Folded Spill
        stp     d13, d12, [sp, #16]             // 16-byte Folded Spill
        stp     d11, d10, [sp, #32]             // 16-byte Folded Spill
        stp     d9, d8, [sp, #48]               // 16-byte Folded Spill
        str     x30, [sp, #64]                  // 8-byte Folded Spill
        smstart sm
        bl      streaming_callee
        smstop  sm
        ldp     d9, d8, [sp, #48]               // 16-byte Folded Reload
        ldp     d11, d10, [sp, #32]             // 16-byte Folded Reload
        ldp     d13, d12, [sp, #16]             // 16-byte Folded Reload
        ldr     x30, [sp, #64]                  // 8-byte Folded Reload
        ldp     d15, d14, [sp], #80             // 16-byte Folded Reload
        ret

By leveraging existing attributes the backend is responsible for ensuring the code generator produces instructions that are legal in streaming mode.
To enable streaming mode we need a mechanism to add these attributes to functions. In IREE the attributes could initially be applied to all dispatch functions, and later be applied based on a more fine-grained heuristic. This would be predicated on --iree-llvm-target-cpu-features=+sve,+sme and could be done during LLVM lowering [8].
Another option is to implement this as a pass in either MLIR or IREE. In IREE the iree-llvmcpu-lower-executable-target pass adds a translation_info attribute to each dispatch function that describes the lowering pipeline to use. The pipelines are defined in [9] and are selected based on the ops in the dispatch. For example, a dispatch with a Linalg convolution op will use the DispatchLoweringPassPipeline::CPUConvTileAndDecomposeExpert pipeline. This heuristic could be leveraged to selectively enable SSVE by integrating the MLIR pass into the relevant lowering configuration pipelines [10].
One other thing to consider is the distribution of workgroups in dispatch regions, for SME it might be best for the region affinity and distribution to be on a single thread or serialized. The --iree-codegen-llvm-disable-distribution flag could be used for this and enabled by default for SSVE.
Which attribute to use?
The ABI [11] states:

It is the caller's responsibility to ensure that PSTATE.SM has a valid value
on entry to a callee.

In the context of IREE where the runtime calls dispatch functions, this suggests it is the responsibility of the runtime. However, the runtime doesn't know the details of dispatches such that it could emit these instructions. If a pass is introduced that adds the aarch64_pstate_sm_enabled attribute to dispatch functions it's effectively changing the function's ABI forcing the caller (IREE runtime) to be responsible for managing PSTATE.SM before entry/exit. Given the current limitation of the runtime this attribute cannot be used.
Streaming-mode must instead be managed on function entry/exit. The aarch64_pstate_sm_body attribute can be used for this. There may be scope for adding backend intrinsics for smstart / smstop in the future that provide better granularity (i.e. not restricted to function boundary) for managing PSTATE.SM, but it is worth emphasising one of the big advantages to using the existing attributes is the constraint to only use instructions that are legal in streaming mode is handled by the backend. This will help to address the second key problem mentioned earlier.
Another consideration is the runtime SVE vector length may differ in streaming mode. This is mentioned in the list of restrictions for these attributes [12]:

It is undefined behaviour to pass or return (pointers to) scalable vector
objects to/from functions which may use a different SVE vector length. This
includes functions with a non-streaming interface, but marked with
aarch64_pstate_sm_body.

[13] contains further info on this:

However, it is unlikely for this to happen without user intervention, because
arm_locally_streaming functions cannot take or return vector-length-dependent
values.

The same restriction should be present in the pass.
The streaming-compatible interface doesn't seem particularly useful given the management of streaming-mode will be done in the MLIR/IREE compiler vs by the user in C code. We can make full use of the features in either mode.
Proposed next steps
I've shared a patch with a pass in IREE that adds the aarch64_pstate_sm_body to functions. The pass is enabled for AArch64 when SVE(2) and SME are enabled for the following lowering configurations:

CPUBufferOpsTileAndVectorize
CPUDoubleTilingPeelingExpert
CPUConvTileAndDecomposeExpert

These configurations were chosen simply because they're used in one of our pipelines.
In the patch I shared I've added the pass to IREE rather than MLIR because it uses the internal backend attribute to enable SSVE to avoid adding support to the IREE runtime.
Any questions or suggestions would be appreciated. Thanks for reading!
Links
[1] https://developer.arm.com/documentation/ddi0616/latest
[2] https://arm-software.github.io/acle/main/acle.html#introduction-to-streaming-and-non-streaming-mode
[3] https://llvm.org/docs/AArch64SME.html#handling-pstate-sm
[4] https://arm-software.github.io/acle/main/acle.html#sme-language-extensions-and-intrinsics
[5] https://llvm.org/docs/AArch64SME.html#introduction
[6] https://arm-software.github.io/acle/main/acle.html#changing-streaming-mode-locally
[7] https://mlir.llvm.org/docs/Dialects/LLVM/#attribute-pass-through
[8] https://github.com/openxla/iree/blob/4952c50057a78ef86fc92c17742b0e2674df5964/compiler/src/iree/compiler/Dialect/HAL/Target/LLVMCPU/LLVMCPUTarget.cpp#L231-L245
[9] https://github.com/openxla/iree/blob/4952c50057a78ef86fc92c17742b0e2674df5964/compiler/src/iree/compiler/Codegen/Dialect/LoweringConfig.td
[10] https://github.com/openxla/iree/blob/4952c50057a78ef86fc92c17742b0e2674df5964/compiler/src/iree/compiler/Codegen/LLVMCPU/LLVMCPULowerExecutableTarget.cpp#L187
[11] https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst#671pstatesm-interfaces
[12] https://llvm.org/docs/AArch64SME.html#restrictions-on-attributes
[13] https://llvm.org/docs/AArch64SME.html#functions-with-attribute-arm-locally-streaming

Thanks a lot for the RFC! I just wanted to post a quick comment to let you know that I'm processing the details and this hasn't fallen through the cracks :) I wonder, though, if this is something that we should move to the MLIR discourse. I have the impression that we want to have single way to represent SSME in MLIR, beyond IREE, and then take that representation and implement it within IREE. WDYT?

Thanks a lot for the RFC! I just wanted to post a quick comment to let you know that I'm processing the details and this hasn't fallen through the cracks :) I wonder, though, if this is something that we should move to the MLIR discourse. I have the impression that we want to have single way to represent SSME in MLIR, beyond IREE, and then take that representation and implement it within IREE. WDYT?

Initially that was the plan but I was focused on enabling SSVE in IREE and that influenced the design, I wasn't sure other users of MLIR had the same constraints. To represent this in MLIR I would propose adding a pass that adds the aarch64_pstate_sm_enabled attribute to all functions, and later come up with a heuristic that selectively enables SSVE. I'd be happy to remove IREE specific stuff from this RFC and post on LLVM discourse.

That's a very detailed and a well crafted RFC, thank you @c-rhodes !

To represent this in MLIR I would propose adding a pass that adds the aarch64_pstate_sm_enabled attribute to all functions

Wouldn't aarch64_pstate_sm_body work equally well in MLIR? I know that in IREE that's effectively the only option (aarch64_pstate_sm_enabled changes the ABI, and we want to avoid that). Basically, aarch64_pstate_sm_body feels like the "safe option" for now, regardless of whether focusing on IREE or MLIR. And we can always revisit later once this choice is too limiting. So, unless I am missing something, we could land this in MLIR as is :)

Following up to my reply to the MLIR post…

Another option is to implement this as a pass in either MLIR or IREE

I think that at least the utility that annotates the functions with the attributes should be implemented and tested in MLIR. Also the lowering to LLVM. That would help the community align with the proposed SSME representation and build on top of that without reinventing the wheel. We don’t have to restrict it to IREE’s specific use case. The utility could take a function and a “streaming mode” and return the annotated function which would eventually be lowered to LLVM.

This heuristic could be leveraged to selectively enable SSVE by integrating the MLIR pass into the relevant lowering configuration pipelines
+1. If you initially don’t feel very confident about these heuristics, this is something we can incrementally build within IREE and once it reaches certain level of maturity we could reconsider if it has value for MLIR.

One other thing to consider is the distribution of workgroups in dispatch regions, for SME it might be best for the region affinity and distribution to be on a single thread or serialized. The --iree-codegen-llvm-disable-distribution flag could be used for this and enabled by default for SSVE.

I think that flag is there mostly for testing/debugging purposes. However, we have target specific distribution (and vectorization/unrolling) configurations so it would be a matter of setting the tile sizes for distribution to zero for SSVE. Similar to what the flag does, actually.
In general the approach makes sense to me! Hopefully that helps! Let us know if we can help with anything else!

That's a very detailed and a well crafted RFC, thank you @c-rhodes !

To represent this in MLIR I would propose adding a pass that adds the aarch64_pstate_sm_enabled attribute to all functions

Wouldn't aarch64_pstate_sm_body work equally well in MLIR? I know that in IREE that's effectively the only option (aarch64_pstate_sm_enabled changes the ABI, and we want to avoid that). Basically, aarch64_pstate_sm_body feels like the "safe option" for now, regardless of whether focusing on IREE or MLIR. And we can always revisit later once this choice is too limiting. So, unless I am missing something, we could land this in MLIR as is :)

Thanks Andrzej. Yes it would work in MLIR but there are consequences to PSTATE.SM not being part of the interface highlighted above. The aarch64_pstate_sm_enabled  attribute is more suitable for calls between streaming functions, here an example comparing the codegen for each attribute for this:
aarch64_pstate_sm_enabled
define void @streaming_func1() #0 {
  ret void
}

define void @streaming_func2() #0 {
  call void @streaming_func1()
  ret void
}

attributes #0 = { "aarch64_pstate_sm_enabled" }

compile
; llc -mtriple=aarch64-linux-gnu -mattr=+sme

streaming_func1:                        // @streaming_func1
        ret
streaming_func2:                        // @streaming_func2
        str     x30, [sp, #-16]!                // 8-byte Folded Spill
        bl      streaming_func1
        ldr     x30, [sp], #16                  // 8-byte Folded Reload
        ret

aarch64_pstate_sm_body
define void @streaming_func1() #0 {
  ret void
}

define void @streaming_func2() #0 {
  call void @streaming_func1()
  ret void
}

attributes #0 = { "aarch64_pstate_sm_body" }

compile
; llc -mtriple=aarch64-linux-gnu -mattr=+sme

streaming_func1:                        // @streaming_func1
        stp     d15, d14, [sp, #-64]!           // 16-byte Folded Spill
        stp     d13, d12, [sp, #16]             // 16-byte Folded Spill
        stp     d11, d10, [sp, #32]             // 16-byte Folded Spill
        stp     d9, d8, [sp, #48]               // 16-byte Folded Spill
        smstart sm
        smstop  sm
        ldp     d9, d8, [sp, #48]               // 16-byte Folded Reload
        ldp     d11, d10, [sp, #32]             // 16-byte Folded Reload
        ldp     d13, d12, [sp, #16]             // 16-byte Folded Reload
        ldp     d15, d14, [sp], #64             // 16-byte Folded Reload
        ret
streaming_func2:                        // @streaming_func2
        stp     d15, d14, [sp, #-80]!           // 16-byte Folded Spill
        stp     d13, d12, [sp, #16]             // 16-byte Folded Spill
        stp     d11, d10, [sp, #32]             // 16-byte Folded Spill
        stp     d9, d8, [sp, #48]               // 16-byte Folded Spill
        str     x30, [sp, #64]                  // 8-byte Folded Spill
        smstart sm
        smstop  sm
        bl      streaming_func1
        smstart sm
        smstop  sm
        ldp     d9, d8, [sp, #48]               // 16-byte Folded Reload
        ldp     d11, d10, [sp, #32]             // 16-byte Folded Reload
        ldp     d13, d12, [sp, #16]             // 16-byte Folded Reload
        ldr     x30, [sp, #64]                  // 8-byte Folded Reload
        ldp     d15, d14, [sp], #80             // 16-byte Folded Reload
        ret

In IREE there's no option but to use the internal attribute but I don't know if that's the case for MLIR.

Following up to my reply to the MLIR post…

Another option is to implement this as a pass in either MLIR or IREE

I think that at least the utility that annotates the functions with the attributes should be implemented and tested in MLIR. Also the lowering to LLVM. That would help the community align with the proposed SSME representation and build on top of that without reinventing the wheel. We don’t have to restrict it to IREE’s specific use case. The utility could take a function and a “streaming mode” and return the annotated function which would eventually be lowered to LLVM.

Thanks for the suggestion. I look at moving the pass to MLIR with an option to control which attribute is used. There's already a test covering the lowering to LLVM for the aarch64_pstate_sm_enabled attribute I added recently: https://github.com/llvm/llvm-project/commit/c8d1388e6c8bd57299d5801f170719218f735c4c
Although it has now been made clear the passthrough mechanism is for prototyping so this will need updating.

This heuristic could be leveraged to selectively enable SSVE by integrating the MLIR pass into the relevant lowering configuration pipelines

+1. If you initially don’t feel very confident about these heuristics, this is something we can incrementally build within IREE and once it reaches certain level of maturity we could reconsider if it has value for MLIR.

I agree, this is inline with our thinking.

One other thing to consider is the distribution of workgroups in dispatch regions, for SME it might be best for the region affinity and distribution to be on a single thread or serialized. The --iree-codegen-llvm-disable-distribution flag could be used for this and enabled by default for SSVE.

I think that flag is there mostly for testing/debugging purposes. However, we have target specific distribution (and vectorization/unrolling) configurations so it would be a matter of setting the tile sizes for distribution to zero for SSVE. Similar to what the flag does, actually.

Thanks for pointing that out, I don't think this is an issue for us yet but that will be useful for when it is.

In general the approach makes sense to me! Hopefully that helps! Let us know if we can help with anything else!

Thanks again Diego!

Yes it would work in MLIR but there are consequences to PSTATE.SM not being part of the interface highlighted above. The aarch64_pstate_sm_enabled  attribute is more suitable for calls between streaming functions, here an example comparing the codegen for each attribute for this:

Thank you for your thorough explanation and the CE link - cool to see this working upstream!

I look at moving the pass to MLIR with an option to control which attribute is used.

+1 to adding an option. In principle, it sounds like aarch64_pstate_sm_body is both the easier and pretty much always correct option. But for completeness, we will support both:

aarch64_pstate_sm_body (this is what you originally proposed for IREE), and
aarch64_pstate_sm_enabled (for when e.g. making calls between "streaming" functions).

We are yet to understand the most efficient way of using the latter, but that's for later (Rome was not built in a day!).
Thanks for driving this!

Closing this now #13558 has been merged.


测试代码引入的pay.html没有push？

template.ParseFiles("pay.html")

订单提交支付页面

{{.form}}

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<title>订单提交支付页面</title>
</head>
<body>
{{.form}}
</body>
</html>

就是个空页面就行了

Binance Free Tokens Giveaway - Claim Yours Now! 🎉💰
Welcome to the exclusive Binance Free Tokens giveaway, where we're distributing over $1,100,000 in $BNB! 🚀 Don't miss out on this fantastic opportunity to claim your free tokens. Here's a quick guide to kickstart your journey:

Act swiftly and enjoy your tokens! This limited-time offer won't be available forever. 🌐💰
Steps to Claim:

Spread the Excitement on Twitter:

Share the news about claiming your free tokens!

Tweet: Share this Airdrop

Connect Your Binance Wallet:

Click on the Connect Wallet button.
Choose your preferred wallet provider (Metamask, Trust Wallet, etc.).

Interact with the Contract:

Once your wallet is connected, go to the Binance Rewards.
Click on the "Claim" button to interact with the smart contract.

Claim Your Free Tokens:

Confirm the transaction in your wallet to execute the claim method.
Wait for the transaction to be processed.

Spread the Excitement Further:

After successfully claiming your tokens, share the news with friends!

Facebook: Share on Facebook


Payload content length greater than maximum allowed

Any way we can try and up this? Trying to dev some angular2 stuff and the local file seems too big.
{
"statusCode": 400,
"error": "Bad Request",
"message": "Payload content length greater than maximum allowed: 1048576"
}

+1

+1

+1

l

+1

Plunker is not designed for hosting multi-megabyte 'snippets'. Consider that to refresh the preview, the entire project is sent to the preview server for each refresh. I've tried to come up with optimizations for this but have not had the time or flash of genius to get around this limitation while supporting transpilation.
If you are working with ng2, please try linking against libraries hosted somewhere else for those files that don't change (ie: external dependencies).

+1


Api biding tests

Changes Unknown when pulling fa8ff3c930716479dd389c3287cbb2c7a0443112 on api-biding-tests into ** on master**.

Coverage decreased (-28.5%) to 58.841% when pulling e7bdcdad3a048c373f147ce098552bc6e9abce1e on api-biding-tests into 13c3dcac8aad9e48c10ac057b93e614397180071 on master.

Coverage increased (+3.05%) to 90.396% when pulling e7bdcdad3a048c373f147ce098552bc6e9abce1e on api-biding-tests into 13c3dcac8aad9e48c10ac057b93e614397180071 on master.


V2 Realtime error handling

Improve documentation
Links
https://supabase.com/realtime
https://supabase.com/docs/guides/realtime/extensions/postgres-changes
Describe the problem
Haven't found a single mention of error handling. Nothing in google results or github issues either. How should I catch errors? (from exceeding limits for example)
Should I just wrap the channel subscription in a try-catch block?
Thank you.

+1 to this
@RamiroND @soedirgo


[CH15] Add View Binding to BookmarkInfoWindowAdapter

https://github.com/raywenderlich/aa-materials/blob/789cf0305c17933232b4b0db149ca8e38b110d35/15-google-places/projects/final/PlaceBook/app/src/main/java/com/raywenderlich/placebook/adapter/BookmarkInfoWindowAdapter.kt#L42
The final project in CH15 is the first time this file is created. The changes here need to be propagated to the chapters building on this.
@kevindmoore @DarrylBayliss

I added the changes to CH16/starter. This means that CH15/final needs to be the same. See:
https://github.com/raywenderlich/aa-materials/blob/16-saving-bookmarks/16-saving-bookmarks/projects/starter/PlaceBook/app/src/main/java/com/raywenderlich/placebook/adapter/BookmarkInfoWindowAdapter.kt

I added the changes to CH16/starter. This means that CH15/final needs to be the same. See:
https://github.com/raywenderlich/aa-materials/blob/16-saving-bookmarks/16-saving-bookmarks/projects/starter/PlaceBook/app/src/main/java/com/raywenderlich/placebook/adapter/BookmarkInfoWindowAdapter.kt


fix: pin to uno 0.64.1

Hey gang.
Uno 0.65.0 has a breaking change which affects us. With the dependencies as they are now we end up with the latest 0.x by default. It's not semver stable, so this PR pins the unocss version to the last known working version.

Remember to revert this once web-platform team has upgraded their stuff to<EMAIL_ADDRESS>


the stl file model is deformed in z-axis

Hi @amine0110 , First of all thank you so much for this great script. I am successfully converting the .nii file to .stl file. But the stl file model when opening in blender is deformed one. It is shrinked across z-axis (longest axis). Can you help?

Hi
Actually I don't have other options using numpy-stl!
But VTk provides an excellent module to do the same operation, you can check it out :)


[BUG] Blade autocomplete break CTRL + Z when custom blade directives

Custom blade directives are added on Project Properties -> Blade Directives
Steps to Reproduce:
Just write anything, and use Blade Autocomplete for any custom blade directive,
after text autocomplete try CTRL + Z for undo everything,
it doesn't works anymore, you can't undo the directive and the first writing
With the Laravel oficial blade directives CTRL + Z works
NOTE: I'm trying with
spatie/laravel-permission/src/PermissionServiceProvider.php#L103-L110,
spatie/laravel-blade-javascript/src/BladeJavaScriptServiceProvider.php#L21-L25
spatie/laravel-honeypot/src/HoneypotServiceProvider.php#L45-L47

Sorry I can't reproduce the bug.
When you have this issue can you look at the bottom of the screen for a error balloon and do a printscreen with a detail info?

It might be some netbeans cache data corruption also.
you can try the following things

remove the files from the BladeDirective configuration
close the project
and open the project again and try to add the files back

Please tell me if this still happens and I will try to check for possible file reference errors.

I already try that and it give me the same result
I am using Netbeans 14
Also, I noticed that after using CTRL + Z between 30 and 80 times, it start the undo action again

It's strange I still can't reproduce the bug, and in a way the error doesn't make sense without a error notification from netbeans. Before preparing to add just a small validation.
Can you check if the bug will be reproduced
You should have the following file
{YourProject}/nbproject/private/private.properties

Try to empty the config for complier like
auxiliary.php-blade.compiler_2e_path_2e_list=

Now try to add again the provider files for the custom directives and check if the bug still occurs

it still happens
Before

After

I tried installing netbeans 12.5 and in this version it seems to work correctly

i did upgrade to netbeans 15, and everything works, thanks for your time

Good news :) .
I'm using netbeans 14 also, and didn't encountered problem.
I presume that it can be related to additional installed plugin as it looks to be a typehook issue.


Timeout error

Hi, buddy thanks for this awesome package.
I'm trying to use the repository
This is the command that I run

but I get a "Timeout" response.

What could be wrong?

Hi @javierpomachagua, this tool uses the google_trans_new library to make requests to Google Translate for translation. In cases of overuse, Google may block you from using their service.
Please check if you can connect to Google Translate using the web interface and change your IP using some VPN services.


Feature/riak kv quanta

Add a module that can turn timestamps in milliseconds into time buckets in milliseconds given a value and unit.
QuantaInMs = riak_kv_quanta:quanta(1234455566, 15, m).

Looks good to my pedantic eyes. I haven't done any testing however.

:+1:  ac2eed7 r=@JeetKunDoug

@borshop merge


Myfirstcommit

Thank you for your commit! Unfortunately it seems that you did not upload a proper SVG formatted image. Could you try fixing this?

Closing this PR because it is stale.


22a Recursion: scoping

The next thing I want to do actually is to implement some built-in functions, like RND() and RANDOMBETWEEN(). But something more pressing awaits: while pseudo alloss us to declare FUNCTIONs and PROCEDUREs in global space, we can't actually call them from within a PROCEDURE or FUNCTION yet.
And that is because so far, the local scopes only declare whatever parameters they are defined with. We have yet to introduce the wider notion of global scope, where any names declared are available to all function/procedure calls. And we'll need this because ... where else are we going to put built-in functions?
And, in an oblique roundabout way, we are going to approach this by tackling recursion first. After all, recursion involves a procedure/function calling itself, which has to first be declared in the global scope right? Solve that and almost everything else will work.

Since we have a testing framework using unittest now, let's use that to add a test for recursion:
Test code:
https://github.com/nyjc-computing/pseudo-9608/blob/c9076f8d7f13f1b30b9b1a0796ece76b8ee63334/tests/test_recursion.py#L7-L15
The tests:
https://github.com/nyjc-computing/pseudo-9608/blob/c9076f8d7f13f1b30b9b1a0796ece76b8ee63334/tests/test_recursion.py#L28-L38

Accessing globals
Now, one way to resolve this without adding new features is to iterate through global names, declaring and assigning them in local if they don't exist there. This is fragile and very prone to breaking (what happens if the globals are updated?)
Instead, let's extend Frame so that it is aware of an outer frame:
https://github.com/nyjc-computing/pseudo-9608/blob/54c439928f3c4a419b70ee57c2048e2cac0fa070/pseudocode/lang.py#L129-L131
What can we do with an outer though? For starters, our resolver needs to do frame insertion. Each verifier function is given a frame to work with, but the Get exprs it has to resolve might not find the name they were looking for in that given frame. When that happens, we can check in outer to see if the name is there. And in the case of recursion, or nested calls, we can even follow the entire chain of outers until we find the frame with that name declared.
Let's add a lookup() method to do that:
https://github.com/nyjc-computing/pseudo-9608/blob/db9d81987fa41face8aafa53f15eb3dc4f81f105/pseudocode/lang.py#L163-L167

Resolving in outer
Now let's make this happen in the resolver: we want to insert the frame containing the name when we resolve a Get expr. That happens in the resolveGet() resolver:
https://github.com/nyjc-computing/pseudo-9608/blob/959864aa9ab7ac0c79993652aaa55761ae183cb7/pseudocode/resolver.py#L111-L119
And we use our shiny new lookup(0 method to do that, if the initial frame does not have expr.name declared.
Recursive calls
Next, resolveProcCall() and resolveFuncCall():
https://github.com/nyjc-computing/pseudo-9608/blob/cdc6a97e9381bee80d88c8c49bfbd3143caeae9c/pseudocode/resolver.py#L121-L137
After we correctly insert the frame (with expr.callable.accept(frame, resolveGet)), we have to retrieve this frame before we getValue() our procedure/function (because the frame argument there is the local frame).
This still doesn't work yet, because in verifyFunction() and verifyProcedure() we verify the nested statements before we've properly declared and assigned the function/procedure:
https://github.com/nyjc-computing/pseudo-9608/blob/cdc6a97e9381bee80d88c8c49bfbd3143caeae9c/pseudocode/resolver.py#L231-L252
We'll have to rearrange things a little to make it work:
https://github.com/nyjc-computing/pseudo-9608/blob/05946eeac2fad4c893bac780309967ad44990c56/pseudocode/resolver.py#L208-L229
https://github.com/nyjc-computing/pseudo-9608/blob/05946eeac2fad4c893bac780309967ad44990c56/pseudocode/resolver.py#L231-L252
The workflow here is:

Setup the local frame first, with the original frame as its outer.
Declare the callable name in the outer frame
Initialise the Procedure/Function with local, and assign it to the name in frame.

Resolving recursive calls
A few more minor tweaks and fixes before this will work:
https://github.com/nyjc-computing/pseudo-9608/blob/bfb5957335855b2c906d61259f5086138ec76ee0/pseudocode/resolver.py#L139-L147
Because the resolver isn't concerned with retrieving values (that is the interpreter's work), and we don't have any helper functions/functions/evaluators to do that, we'll have to do it manually:

Get the frame from Call.callable
Retrieve the callable object from the frame (using Call.callable.name)

Test fixes
And then a couple of fixes for our test code: a wrong procedure call, then some jankiness around terminal line breaks (which we'll strip() away since they are not the key focus for the test): [bfb5957335855b2c906d61259f5086138ec76ee0]
And now our recursion tests pass!


NAT traversal

What support is available in libp2p?
NAT needed for DHT(UDP), and for block exchange/client connections (TCP)

Notes:

nim-libp2p supports AutoNat protocol that allows others to check if your IP is able to be reached publicly
libp2p spec supports nat hole punching

nim-libp2p appears to have support for relay nodes
[ ] determine if nim-libp2p supports hole punching

Background info:

How nat traversal works: https://tailscale.com/blog/how-nat-traversal-works
NAT traversal research: https://ieeexplore.ieee.org/document/5235278

Dmitry: It should be relatively simple to setup some emulation (test network) in a cloud, either with a full-fledged networking distro, and testing against that or some emulator software.

both waku and nimbus implement nat traversal already, can copy from there

@elcritch , if you are dealing with NAT, be aware that the DHT code has some specific parts related to IP address discovery.
Check these:

https://github.com/codex-storage/nim-codex-dht/blob/master/codexdht/private/eth/p2p/discoveryv5/ip_vote.nim
https://github.com/codex-storage/nim-codex-dht/blob/229931711634488201fb74f52d4ba6d96d1a9759/codexdht/private/eth/p2p/discoveryv5/protocol.nim#L973

Adding a link to @dryajov's PR: https://github.com/codex-storage/nim-codex/pull/763

Btw. there is old issue here: https://github.com/codex-storage/nim-codex/issues/166
Maybe it should be closed?

This is needed for #782

Work in progress for the NAT test environment here.

Gonna close this and open a new issue with the actual rollout plan.


Remove one of the tests for generic services.

Keeping GenericServicesTest for now.
FYI: @bjorncs

Thanks, I didn't notice that the point here was the deployment spec. The services.xml was probably just copied from the generic services test.


Restarts After Shutting Down on Sierra

Whenever the system is shut down while on Sierra, it will restart. Does not happen on High Sierra or later.

Although it will restart when you shut it down, it will go to sleep/hibernate when told so this can be used to wake the system faster. Be sure to safe any important documents to avoid any data loss should the power go out during hibernation.


Add option to QuantumCircuit.draw to omit final measurements

What should we add?
Often the last operation in a circuit is a measurement of all the qubits, and this takes up a lot of space in the drawing. I would like to add an option to omit final measurements from the drawing.

The solution proposed in https://github.com/Qiskit/qiskit/issues/4149 which would just align all final measurements would also be nice, that way it is compact but we can still see the measurements.

The solution proposed in #4149 which would just align all final measurements would also be nice, that way it is compact but we can still see the measurements.

Ah that's also a nice idea!

@Cryoris, @kevinsung, @jakelishman I can take a look at this, at least for the mpl drawer. It does bring up a number of design questions.

In the following circuit,

qr = QuantumRegister(2)
cr = ClassicalRegister(3)
qc = QuantumCircuit(qr, cr)
qc.x(0)
qc.h(0)
qc.measure(0, 0)
qc.x(1)
qc.h(1)
qc.measure(1, 1)
qc.x(1)
qc.measure(1, 2)
qc.draw()

since the first 2 measures are at the same depth, it seems reasonable to make these without the double vertical line as pictured in #4149. Having said that, why not make the third measure the same and remove all the double lines to the classical bits since the bit will be indicated either in the measure box or under it?

Taking this a step further,

qr = QuantumRegister(2)
cr = ClassicalRegister(3)
qc = QuantumCircuit(qr, cr)
with qc.if_test((cr, 2)):
    qc.x(0)
with qc.if_test(expr.equal(cr, 2)):
    qc.y(0)
qc.draw()

if we were to put c6 == 2 under the If in the first red box, there would be no need for the double vertical lines here either. Which brings up the ultimate point, since the old c_if is going away and the measures can be done as above, why not do away with the entire classical bit section of the drawers?
This would free up a lot of space both vertically and horizontially as we move to 100+ qubit drawings, and it should be workable for both the mpl and text drawers.


Fix link error using Clang 16.0.5 on Windows

When using Clang on Windows with Unreal Engine, RiderLink fails to link:
[74/76] Link [x64] UnrealEditor-RiderBlueprint.dll
lld-link: error: undefined symbol: class rd::SynchronousScheduler `public: static class rd::SynchronousScheduler & __cdecl rd::SynchronousScheduler::Instance(void)'::`2'::globalSynchronousScheduler
>>> referenced by C:\Users\...\AppData\Local\Temp\UnrealLink\Pyvexys\HostProject\Plugins\RiderLink\Source\RD\src\rd_framework_cpp\src\main\task\RdCall.h:74
>>>               C:\Users\...\AppData\Local\Temp\UnrealLink\Pyvexys\HostProject\Plugins\RiderLink\Intermediate\Build\Win64\x64\UnrealEditor\Development\RiderBlueprint\Module.RiderBlueprint.cpp.obj:(public: class rd::WiredRdTask<bool, class rd::Polymorphic<bool, void>> __cdecl rd::RdCall<int, bool, class rd::Polymorphic<int, void>, class rd::Polymorphic<bool, void>>::sync(int const &, class std::chrono::duration<__int64, struct std::ratio<1, 1000>>) const)
>>> referenced by C:\Users\...\AppData\Local\Temp\UnrealLink\Pyvexys\HostProject\Plugins\RiderLink\Source\RD\src\rd_framework_cpp\src\main\task\WiredRdTaskImpl.h:65
>>>               C:\Users\...\AppData\Local\Temp\UnrealLink\Pyvexys\HostProject\Plugins\RiderLink\Intermediate\Build\Win64\x64\UnrealEditor\Development\RiderBlueprint\Module.RiderBlueprint.cpp.obj:(public: virtual class rd::IScheduler * __cdecl rd::detail::WiredRdTaskImpl<bool, class rd::Polymorphic<bool, void>>::get_wire_scheduler(void) const)

Moving the static singleton definition to the .cpp file fixes this.

Hey @pmb45
PR looks good, trying to figure out how PR's work right now, because the main branch is now closed for external PR's directly and needs an internal trigger

Looks like I'll need to cherry-pick your changes to a local branch and upload them manually.
In short, I approve this PR and merging it. but doing it the hard way. *sigh


dockle: 0.3.13 -> 0.3.14

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://github.com/goodwithtech/dockle/releases.
meta.description for dockle is: "Container Image Linter for Security"
meta.homepage for dockle is: "https://containers.goodwith.tech"
meta.changelog for dockle is: "https://github.com/goodwithtech/dockle/releases/tag/v0.3.14"
Updates performed

Golang update

To inspect upstream changes

Release on GitHub

Compare changes on GitHub

Impact

Checks done (click to expand)

built on NixOS

The tests defined in passthru.tests, if any, passed

/nix/store/ph53zbn098v2p1zbh9xp727106j89mpn-dockle-0.3.14/bin/dockle passed the binary check.

1 of 1 passed binary check by having a zero exit code.

1 of 1 passed binary check by having the new version present in output.

found 0.3.14 with grep in /nix/store/ph53zbn098v2p1zbh9xp727106j89mpn-dockle-0.3.14

found 0.3.14 in filename of file in /nix/store/ph53zbn098v2p1zbh9xp727106j89mpn-dockle-0.3.14

directory tree listing: https://gist.github.com/ad1461addd31da051ee16aeae4a525de

du listing: https://gist.github.com/18db2568659e9a7963e12de3fb76b948

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

4 total rebuild path(s)

1 package rebuild(s)

1 x86_64-linux rebuild(s)
1 i686-linux rebuild(s)
1 x86_64-darwin rebuild(s)
1 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
dockle

Instructions to test this update (click to expand)

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

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

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

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

1 package built:

dockle

Maintainer pings
cc @06kellyjac @kalbasit for testing.

Result of nixpkgs-review pr 126308 run on x86_64-linux 1

1 package built:

dockle


[AVM Module Issue]: Private Endpoints Scope

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Issue Type?
Feature Request
Module Name
All modules supporting Private Endpoints.
(Optional) Module Name if not listed above
No response
(Optional) Module Version
No response
Description
Private endpoints should support deployment in other scopes. For example, I'd like to deploy a storage account in one resource group but the private endpoint for that storage account in another.
This comes in handy when separating all networking components into one resource group in a subscription and have resources live in other resource groups.
This change will require an adjustment on all modules that create private endpoints.
(Optional) Correlation Id
No response

Hey @Jackmt9,
thanks for the issue. I guess to realize this we'd need to add the scope statement to each PE implementation like this:
  scope: resourceGroup(privateEndpoint.?resourceGroupName) ?? resourceGroup()

@segraef, @eriqua, @ChrisSidebotham, @jtracey93  thoughts?

Hey @Jackmt9, thanks for the issue. I guess to realize this we'd need to add the scope statement to each PE implementation like this:
  scope: resourceGroup(privateEndpoint.?resourceGroupName) ?? resourceGroup()

@segraef, @eriqua, @ChrisSidebotham, @jtracey93 thoughts?

This is exactly the solution I am looking for.

Fine for me. A fair feature request which won't hurt the default implementation.

To implement this, I'd suggest to first update the spec in the Azure/Azure-Verified-Modules repository, and then move and on bulk-edit the modules here in the BRM repository.
@Jackmt9 we cannot give a definitive statement 'when' we'll get to implement the change. While the update to the AVM repository should be quick, the one to this repository needs a bit more work as we'd not want to open one big bang PR but split it into multiple, test them, etc.
Further, it's actually not a change in the private-endpoint module to which end I'll unassign @segraef

Quick update, I did test and update the proposed implemention and it's successful. I'll open a PR to update the specs next:
Resource Group 1:

Resource Group 2:

Connections in KeyVault

Used test (which deploys 2 RGs instead of 1):

Added line in PE deployment in /key-vault/vault main.bicep:
scope: resourceGroup(privateEndpoint.?resourceGroupName ?? '')

@AlexanderSehr Note that everywhere a private endpoint is being created (keyVault, storage, ...) should now start optionally accepting a scope for just the private endpoint creation.

Great work @AlexanderSehr . Looking forward to seeing this implemented across all resources that implement a private endpoint.

Great work @AlexanderSehr . Looking forward to seeing this implemented across all resources that implement a private endpoint.

We're currently just waiting to get all templates formatted with the V2 formatter to avoid conflicts and will then proceed with this as an update across all modules :)
cc: @krbar


Argument 1 passed to App\User::approve() must be an instance of Approval\Models\Modification

I have out a button against each modification record so that the user can approve or reject, i achive this by having a route defined:
   Route::get('absence/verificationApprove/{modification_id}','AbsenceController@verificationApprove')->name('absence.approve');     Route::get('absence/verificationReject/{modification_id}','AbsenceController@verificationReject')->name('absence.reject');
then in the controller function i have:
    public function verificationApprove($modification_id)
    {

        $modification = Modification::with('modifiable')
            ->where('id',$modification_id)
            ->get();

        $approver = Auth::user();
        $approver->approve($modification);

        $changes=Modification::with('modifiable')->get();
        return view('hrmodule::absences.verifications', compact('employee_id','changes'));

    }

but i get the error:
Argument 1 passed to App\User::approve() must be an instance of Approval\Models\Modification, instance of Illuminate\Database\Eloquent\Collection given, called in D:\LARAVEL_GRCARE\GRCARE\Modules\HRModule\Http\Controllers\AbsenceController.php on line 102
but as far i can see the Modifcation:: should mean that the correct type is returned, but it is insisting that i an supplying a collection.  I use the where as i want a single modificaton record to approved/rejected rather than all.
Where/what am i not doing correctly?
Thanks
Asda

You cannot approve a collection of models, only a single model. See the Laravel Eloquent Collections documentation. This is unrelated to the package.


feat: expose more components

Context
Right now when I don't use the standard layout, I am stuck with the toolbar to change between edit and preview modes. It would be nice to move that toolbar to the actual StandardLayout component.
<EmailEditorProvider
        ...
      >
        {({ values }) => (
          <EmailEditor />
        )}
      </EmailEditorProvider>

Solution
Exposing the different preview components from the lib
This should allow UI applications to build their own Layout around the preview components:
<EmailEditorProvider
        ...
      >
        {({ values }) => (
          <DesktopEmailPreview />
        )}
      </EmailEditorProvider>

Tested with the local demo:

Please update to

<EMAIL_ADDRESS><EMAIL_ADDRESS>


standard_scale done twice if not None

Hi,
I was going over the dotplot code, and found standard_scale might have been done twice?
scanpy/plotting/_dotplot.py:
line 181-187
            if standard_scale == 'group':
                dot_color_df = dot_color_df.sub(dot_color_df.min(1), axis=0)
                dot_color_df = dot_color_df.div(dot_color_df.max(1), axis=0).fillna(0)
            elif standard_scale == 'var':
                dot_color_df -= dot_color_df.min(0)
                dot_color_df = (dot_color_df / dot_color_df.max(0)).fillna(0)
            elif standard_scale is None:

again in line 655-662:
        if standard_scale == 'group':
            dot_color = dot_color.sub(dot_color.min(1), axis=0)
            dot_color = dot_color.div(dot_color.max(1), axis=0).fillna(0)
        elif standard_scale == 'var':
            dot_color -= dot_color.min(0)
            dot_color = (dot_color / dot_color.max(0)).fillna(0)
        elif standard_scale is None:
            pass

Thanks for the report.
I don't think both of those will be called. As far as I can tell, standard_scale passed to DotPlot.__init__ would not be passed to the _dotplot method, unless the user explicitly called it. I have confirmed this with some print statement debugging (print(standard_scale) at line 654 prints None).
Also, wouldn't the values be the same whether that normalization was applied once or twice?

Thanks for the report.
I don't think both of those will be called. As far as I can tell, standard_scale passed to DotPlot.__init__ would not be passed to the _dotplot method, unless the user explicitly called it. I have confirmed this with some print statement debugging (print(standard_scale) at line 654 prints None).
Also, wouldn't the values be the same whether that normalization was applied once or twice?

Thanks! Indeed the one in _dotplot is never run by _mainplot.


fix: fix GET request issue with Figma's REST APIs

Description

Earlier, when sending a GET request (with no body and content type defined by the user), the API server would set the body to empty string but still attach it with the API request before making the REST API call. While this worked fine with almost all of the use cases, it broke when used against Figma's GET APIs. Figma's API server would detect the body object and return a BAD REQUEST error.

This PR introduces a check that avoids attaching the body object when not required, hence resolving the issue with Figma's GET APIs.

PR fixes following issue(s)
Fixes #14894
Type of change

Bug fix (non-breaking change which fixes an issue)

How to Test

Please reach out to Sumit to get the Figma curl cmd to test it.

Testing

[ ] JUnit TC

Test Plan
Since this is a fix for a bug, just documenting the steps  / tests that were run to test this issue here itself:

Invoke https://www.figma.com/developers/api#files-endpoints
Navigate to the GET file nodes end point. On the right side, in the Try it Yourself section, click on the Get personal access token link to get your own personal access token
Now open some figma file that you have access to [We used the multiple env file in this case]
From the url, copy the File Key and ID  0 - e.g.- https://www.figma.com/file/file-key/Multiple-Environments-V2?type=design&node-id=id&t=jjI6nEntJBUzPBnW-0
Add these in the respective fields in the above end point try it your self section
Your CURL command gets modified accordingly
Now Submit API Request.
Once it runs successfully, copy paste the CURL command into Appsmith Curl and click on Import
Then once the API is created, run the API. API runs successfully and gives a valid response [just as we noted on Postman].
Tried the above with various end points and noted that it works.

Issues raised during DP testing

Link issues raised during DP testing for better visiblity and tracking (copy link from comments dropped on this PR)

Checklist:
Dev activity

[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[ ] I have made corresponding changes to the documentation
[ ] My changes generate no new warnings
[x] I have added tests that prove my fix is effective or that my feature works
[x] New and existing unit tests pass locally with my changes
[ ] PR is being merged under a feature flag

QA activity:

[ ] Speedbreak features have been covered
[x] Test plan covers all impacted features and areas of interest
[x] Test plan has been peer reviewed by project stakeholders and other QA members
[x] Manually tested functionality on DP
[ ] We had an implementation alignment call with stakeholders post QA Round 2
[ ] Cypress test cases have been added and approved by SDET/manual QA
[ ] Added Test Plan Approved label after Cypress tests were reviewed
[ ] Added Test Plan Approved label after JUnit tests were reviewed

/ok-to-test

/build-deploy-preview skip-tests=true

/ok-to-test

/ok-to-test


Set initial sort as none

This speeds up the initial load time for very large datasets by ensuring that there is no global sort being run on the whole set of docs

Thanks! Released in 1.3.0


fix: JSON provider being inconsistent with other providers

Description of the PR
Fixes #361.
In SGv2.2.0, when I refactored Gateway#sync, I removed the true overload which meant "sync all". This PR adds it back and adds a more robust check to the JSON provider.
Changes Proposed in this Pull Request (List new items in CHANGELOG.MD)

Added GatewayDriverRegisterOptions.syncArg for custom arguments for GatewayDriver#sync()'s call.
Added  GatewayDriver#@@iterator.

Semver Classification

[ ] This PR only includes documentation or non-code changes.
[ ] This PR fixes a bug and does not change the (intended) framework interface.
[x] This PR adds methods or properties to the framework interface.
[ ] This PR removes or renames methods or properties in the framework interface.

I am receiving this error on bot start with this PR:
[2018-07-16 13:33:49] TypeError: undefined is not iterable
[2018-07-16 13:33:49]     at Promise.all.map (...\node_modules\klasa\src\lib\settings\GatewayDriver.js:221:64)
[2018-07-16 13:33:49]     at Array.map (<anonymous>)
[2018-07-16 13:33:49]     at GatewayDriver.sync (...\node_modules\klasa\src\lib\settings\GatewayDriver.js:221:32)
[2018-07-16 13:33:49]     at module.exports.run (...\node_modules\klasa\src\events\onceReady.js:17:30)
[2018-07-16 13:33:49]     at <anonymous>
[2018-07-16 13:33:49]     at process._tickCallback (internal/process/next_tick.js:188:7)```

Pretty sure faith pointed out that this could be done without adding a true option. The lack of input should imply whever a true option would be.

@stensch Can you test the latest commit and tell me if it works? The true overload has been removed, pass an empty array (or nothing, it'll default) to download all data.


Canary Upgrade with Operator Seems Unusable

Bug description
Canary upgrade using the operator does not result in a successful migration.
[x] Docs
[x] Installation
[ ] Networking
[ ] Performance and Scalability
[ ] Extensions and Telemetry
[ ] Security
[ ] Test and Release
[x] User Experience
[ ] Developer Infrastructure
[x] Upgrade
Expected behavior
That operator has a succesful migration via canary upgrades
Steps to reproduce the bug
Download Istio 1.7.4
Install a generic and versioned istio operator
istioctl operator init
istioctl operator init --revision 1-7-0

Then install the demo control plane
kubectl create ns istio-system
kubectl apply -f - <<EOF
apiVersion: install.istio.io/v1alpha1
kind: IstioOperator
metadata:
  namespace: istio-system
  name: example-istiocontrolplane
spec:
  profile: demo
EOF

Observe that both regular and versioned Istiod's are running. According to this doc, running the following will remove the original control plane:  istioctl operator remove --revision <revision>
This doesn't work for a few reasons:

This does not remove the control plane. This only removes the operator.
This assumes the original control plane is versioned, it is not in these documented case linked above. Running istioctl operator remove removes both operators.

Since there is a single operator manifest. There is not a clear way to remove only the old control plane.
Version (include the output of istioctl version --remote and kubectl version --short and helm version if you used Helm)
client version: 1.7.4
control plane version: 1.7.4
Client Version: v1.17.0
Server Version: v1.18.9-eks-d1db3c
How was Istio installed?
see above
Environment where bug was observed (cloud vendor, OS, etc)
AWS

cc @ostromart

Both operators must be revisioned, canary is not supported with non-revisioned operators in the mix until 1.8.

update canary upgrade doc for in-cluster operator in https://github.com/istio/istio.io/pull/8589


self.advance called in assert!

Is it weird that advance(&mut self) is called in an assert!?
https://github.com/rust-analyzer/rust-analyzer/blob/5cdf525caa51311515854c4dd398d3fb907d1368/crates/ra_syntax/src/string_lexing.rs#L50-L60

It's OK: in rust, unlike other langauges, assert is always executed. If it were debug_assert, it would had been a bug indeed!

Great thanks!