#199 resizable dashboard

Overview
Completes #199
A way for the user to resize the RHS and LHS to improve readability of the compare tab and search list.
What Changed
Changes in dashboard/index.tsx swapped grid for react-resizable-panels to display the RHS & LHS. There are functions to show the correct UI when accessing from desktop or mobile.
Other Notes
Several Libraries were attempted, but react-resizable-panels worked best for our needs.

@AbhiramTadepalli double check LHS getting too small and mobile issues
maybe also snapping back to 50/50?

Mobile seems to work on firefox for me but not chrome, may just need to go back to the old Grid based on a useMediaQuery

@AbhiramTadepalli this should be ready now except I can't seem to get the sticky RHS working when merging in develop

@AbhiramTadepalli Ok figured it out. Apparently overflow hidden on any parents screws with position sticky. All ready now.

Okay so every time you add to compare it makes the rhs's minimum width wider. imo minwidth should stay the same because we have horizontal scroll in compare

Idk why setting min width fixes this but it does

ah sorry. Bug:

Make LHS bigger,
open a card,
make LHS smaller,
the LHS does not get smaller, RHS just moves on top of it. Expected behavior is LHS resizes (including the contents of the card)

@TyHil one last question The LHS locks at a min-width. In split-screen (when the browser window is half the size) the RHS keeps going until the edge of the name. Is that the intended behavior?
In full-screen, the RHS just stops at the LHS's min-width

i dont't quite get this, can you screenshot?

ah sorry. Bug:
1. Make LHS bigger,

2. open a card,

3. make LHS smaller,

4. the LHS does not get smaller, RHS just moves on top of it. Expected behavior is LHS resizes (including the contents of the card)

im getting this behavior like 1 in 10 times, but if you re expand the LHS and re collapse it behaves as intended. is that acceptable?

@TyHil one last question The LHS locks at a min-width. In split-screen (when the browser window is half the size) the RHS keeps going until the edge of the name. Is that the intended behavior?
In full-screen, the RHS just stops at the LHS's min-width

i dont't quite get this, can you screenshot?

It covers the bubbles, does not make the row skinnier

im getting this behavior like 1 in 10 times, but if you re expand the LHS and re collapse it behaves as intended. is that acceptable?

Do you know why it's inconsistent? Or the cause?

I have no idea

Since it mostly works, I'll merge it in

[ ] [Bug]: Resizable dashboard does not shrink an expanded card on the LHS, sometimes


docs/Linuxbrew: Best-effort support for ARM64 (AArch64)

@vielmetti The just-released Homebrew 2.0.3 will now install on AArch64! I fixed the issue with OpenSSL. The installation instructions at http://linuxbrew.sh should work for AArch64.

Thank you @sjackman ! I'll report back any successes or reports of issues.


[Frontend] awes-io/awes-io prototype with Nuxt

add a Nuxt to client folder in the root
package.json in root folder

➤ Ilya Kitayev commented:
https://git.awescode.com/awes-io/awes-io/merge_requests/10 ( https://git.awescode.com/awes-io/awes-io/merge_requests/10 )
Package.json in root folder proxies watch, build, start and generate commands from the ./client folder and shows a warning, when you try to install dependencies from the root folder.
{quote}Note! Client dependencies should only be installed in the ./client folder{quote}


Compiler allows comparing a comparable to a literal number

SSCCE
This should fail to compile, but it doesn't:
module Bug exposing (bug)

bug : comparable -> Bool
bug n =
    n == 1

Running the code doesn't produce a runtime exception, but it does return some strange results.
import Bug exposing (bug)

bug 1
> True

bug 'a'
> False

bug ""
> False

bug "asdf"
> False

bug []
> False

bug (0)
> True

bug (1)
> False

This bug only occurs when comparing a comparable to a literal number (as in, the number is hardcoded). For example, this correctly fails to compile:
bug : comparable -> number -> Bool
bug n a =
    n == a

Environment
$ elm --version
0.18.0

$ elm-repl --version
0.18.0

$ node --version
v8.1.0

$ sw_vers
ProductName:	Mac OS X
ProductVersion:	10.11.6
BuildVersion:	15G1108

Edit: Added environment info

@fbonetti, on the mailing list you asked whether this is a known problem. It does look like one of this conglomerate: #1581, #1268, #1270, #1281, #1316, which according to https://github.com/elm-lang/elm-compiler/issues/1373#issuecomment-300928646 are fixed (but the fix not yet in a released version of the compiler).

@jvoigtlaender Thanks for looking into this. It does look like the same issue.

Error from the new compiler:
-- TYPE MISMATCH -------------------------------------------------

The right side of (==) is causing a type mismatch.

133|     n == 1
              ^
(==) is expecting the right side to be a:

    comparable

But the right side is:

    number

Hint: Your type annotation uses type variable `comparable` which means any type
of value can flow through. Your code is saying it CANNOT be anything though!
Maybe change your type annotation to be more specific? Maybe the code has a
problem? More at:
<https://github.com/elm-lang/elm-compiler/blob/0.19.0/hints/type-annotations.md>

Hint: With operators like (==) I always check the left side first. If it seems
fine, I assume it is correct and check the right side. So the problem may be in
how the left and right arguments interact.

Thanks!!


aka.ms link isn't pointing anywhere

The link https://aka.ms/armwhatifissues doesn't go anywhere, it just leads to microsoft.com
See https://docs.microsoft.com/en-us/azure/azure-resource-manager/template-deploy-what-if#next-steps

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

ID: 0944bfc2-8ecb-ce0f-765a-d1ab66302480
Version Independent ID: 4e1db8ad-3495-b1b0-c9ac-e3510295148d
Content: Template deployment what-if (Preview) - Azure Resource Manager
Content Source: articles/azure-resource-manager/template-deploy-what-if.md
Service: azure-resource-manager
GitHub Login: @mumian
Microsoft Alias: jgao

Thanks for your comment. We are actively investigating and will get back to you shortly. Thanks for your patience.

@benc-uk - thanks for making us aware of this broken link. I have submitted a change to use https://aka.ms/whatifissues. It should get published this afternoon.

#please-close


Bump version to 2.7

Description
[Describe what this change achieves]
Issues Resolved
[List any issues this PR will resolve]
Check List

[x] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

we should have a separate PR to fix test failure of github actions.

we should have a separate PR to fix test failure of github actions.

Agreed, working on that.


Implement new download requirements script (#805)

rsync added to the Dockerfile

Maybe there was a different discussion with @to-bar  but my understanding was we wanted to do this in Ansible?
IF we are using Python all code is compatible with Python 2.7>? Yes 2 is deprecated but RedHat is still using 2.7 that I think.
rsync would also be added to the devcontainer.
Dependency list would be nice to have in YAML and images and files might be shared across distros as they are the same. Platform would still have seperation between AMD/ARM.

I did research on my own and found out that Ansible is not suitable for such feature. Python solution is shorter, faster and more elastic than Ansible approach. I also considered Ansible modules but they were designed for other purposes, this is more of a standalone script. In my opinion you should look at the code and consider if it's a fine code and we're ok with it, or maybe there is something wrong and we cannot go on with this kind of approach.
No need for python 2.7, both RedHat and Centos support Python 3.6+
Thanks, I've added rsync to the devcontainer
My fault, I did not look at those files and thought that each distro has it's own set of images and files. No need for YAML since python modules are very flexible and in this case much faster than loading and parsing YAML. I came out with a simple solution to share common files and images.

I did research on my own and found out that Ansible is not suitable for such feature. Python solution is shorter, faster and more elastic than Ansible approach. I also considered Ansible modules but they were designed for other purposes, this is more of a standalone script. In my opinion you should look at the code and consider if it's a fine code and we're ok with it, or maybe there is something wrong and we cannot go on with this kind of approach.

Didn't research but for me Ansible solution seems to be shorter since it provides ready to use modules like get_url, apt, yum, docker_image (requires Docker daemon), and shell. Downloading requirements probably could be implemented by calling those in loops (for example iterate over list of URLs).  For tools like crane we could write our own module (if not exists in Ansible Galaxy).

No need for python 2.7, both RedHat and Centos support Python 3.6+
RHEL/CentOS 7 out of the box has only Python 2 but it is possible to install Python 3. So this will be prerequisite. Open question whether it should be automated on our side or provided (installed) by user on his own.

IMO the main goal of this task is not just get rid of Bash but speed up downloading on rerun. To achieve this we may need to rely on checksums in order to detect corrupted files (downloaded only partially) to re-download them. Are you going to add checksums?

Dependency list would be nice to have in YAML

Agree.  It's a good practice to store data/configuration in a format that can be parsed by other tools - for example in case we decide to download something using Ansible.


Cannot start project

Cannot start project

whats the issue? please share more information

in the pom.xml under the spring-cloud-config-server dependency i added the version and it ran with no issues do that and it should run. Especially if you are getting a git error.
Hope this helps someone.


types(remix-server-runtime): make AppLoadContext an empty interface instead of any

this allows users to override the context with their own definitions using ambient modules.
as an example:
declare module "remix" {
  interface AppLoadContext {
    graphql: <Result, Variables>(operation: {
      query: TypedDocumentNode<Result, Variables>
      variables: Variables
    }) => Promise<ExecutionResult<Result>>
  }
}

What does this do if you don't add that declare? Does it treat it as any or are you required to declare it?

do you mean the declare in my example? it's my understanding that it's not a valid ambient module declaration without it

What does this do if you don't add that declare? Does it treat it as any or are you required to declare it?

If you don't add the declare, the type of context will be {}. This PR allows you to add a declare to change the context type to whatever you want. This is similar to declaring a type to extend the express request: https://stackoverflow.com/a/40762463/1332403

This is how I currently override the type for context it's quite hard btw. I'm agreed with this PR since typescript will merge the interface with the same name within a module.
https://github.com/rootblack45/rootblack45.me/blob/484988376882c900beb0b08663afdeca85142d0d/app/types.d.ts#L3-L16

Sorry, I'm not as well-versed in TypeScript as you might expect, I just know enough to get by.
I understand this PR enables you to do this:
declare module "remix" {
  interface AppLoadContext {
    graphql: <Result, Variables>(operation: {
      query: TypedDocumentNode<Result, Variables>
      variables: Variables
    }) => Promise<ExecutionResult<Result>>
  }
}

What if in my app I don't declare anything and I add load context and try to access it, what will the type be?
export let loader: LoaderFunction = async ({ context }) => {
  // what is context? Any? Can I access stuff on it w/o typescript getting mad?
  console.log("is TS mad?", context.foo);
}

I'd like TypeScript to treat it as any.

What if in my app I don't declare anything and I add load context and try to access it, what will the type be?

That should be undefined since this just allows us to work with types easier. It's like javascript if the value doesn't exist in the object so that value should be undefined

I don't know why this question is so hard for me to ask and get an answer that makes sense to me 😅
With this PR, do I get red squiggly lines under context.foo if I don't declare an app load context type?

I think the answer is yes. Typescript playground example

Do you have to have an empty interface to be able to do this or can you do it if it's typed as any?
declare module "remix" {
  interface AppLoadContext {
    /* type here */
  }
}

There are other things like namespaces that support declaration merging, but type does not. You get a "duplicate identifier" warning (typescript playground).

Do you have to have an empty interface to be able to do this or can you do it if it's typed as any?

You need to do that only if you want to add new properties to an interface. After that Typescript will merge the properties after you declare.

This PR is just for better DX since esbuild doesn't care what you declare in the type system 😂

@itsMapleLeaf ah, okay, I can maybe live with that? Don't like that it has to be an object now, but seems weird to be anything else.
@mjackson you have an opinion here?

@ryanflorence Just came here after almost having opened a similar PR myself. This is the signature for AppLoadContext I'd recommend instead of an any type, which doesn't allow for declaration merging and therefore can't be strongly typed:
export declare interface AppLoadContext {
	[key: string]: unknown
};

This will continue allowing accessing any properties on AppLoadContext by default, but prevents unsafe property access by requiring type assertions at runtime. For those that prefer strict typing and know the structure of their context in advance, they can merge this generic interface declaration with their own.

@DanielFGray Code/type changes go against dev.
Could you please rebase your branch onto latest dev & set base branch to dev too?

I have updated this to use unknown, per @3x071c's suggestion
@MichaelDeBoey I think I rebased this properly

Looks like it includes changes that weren't in this PR. Might want to reflog and or rebase again. Looking forwards to this being merged in as we have a similar use case.

@DanielFGray Like @marwan38 said: the rebase included changes that doesn't belong in this PR.
Please remove these from your branch/PR.

@DanielFGray Could you please rebase your branch onto latest dev & resolve conflicts?

@MichaelDeBoey I've cherry-picked the authors commits and added a few of mine own. https://github.com/remix-run/remix/pull/3422
Not to discourage the author, I just want to get this into the repo :).

@marwan38 Please put remarks/suggestions in this PR instead of creating a separate PR.

@marwan38 Please put remarks/suggestions in this PR instead of creating a separate PR.

I found an issue while trying out the changes introduced in this PR. The type references to the AppLoadContext were erroring out due to the other references being types as unknown.
- type AppLoadContext = any;
+ interface AppLoadContext {
+    [key: string]: unknown;
+ }

// Other functions that rely on the context
const someLoaderThing = (loadContext: unknown) => { // ... } // type error, type unknown conflicts with the new interface

I made a few changes that fixed this issue, they can be seen here: https://github.com/remix-run/remix/pull/3422/files

@MichaelDeBoey just out of curiosity, at what point could we consider this stale or abandoned and give someone else a chance to get it across the finish line? I think this is a pretty large impact item for our company since our apps will all rely on this context. Let me know, I'm definitely willing to help!

@justinwaite If you're willing to actively working on this, you can always open a new PR, since @DanielFGray isn't responding for over a month now.

@justinwaite If you're willing to actively working on this, you can always open a new PR, since @DanielFGray isn't responding for over a month now.

@MichaelDeBoey I literally just pushed a new commit yesterday. I'm still working out some of the kinks since a lot of things changed since I first filed this, and I'm also having trouble running the test suite locally which I've been asking for help with in the Discord #contributions channel.
I'm very interested in having this merged and actively working fixing on the remaining failing tests.

@DanielFGray Oh sorry, I looked over that commit, I only saw @justinwaite's message en then the Changeset message 🙈
@justinwaite Let's continue with this PR instead of creating a new one.

Out of curiosity, what do you need the tests for? Running a type check should be all you need since all that's being change is the type definitions.

Hey all! Coming to this conversation a little late, but I've read through the approach here and it looks good 💯
We're putting some extra effort into type safety recently and this is the next thing on the docket. @DanielFGray let me know if there's any way I can help or support the awesome work you're doing! Happy to collaborate or support in whatever way.

I don’t think the documentation for this is newbie-friendly. It’s not clear where this declaration is supposed to reside, or whether it’s supposed to change for adapters—are you supposed to override @remix-run/server-runtime or @remix-run/{adapter}?

If anyone is visiting this issue after banging your head against the wall, if you choose to keep the module augmentation in a separate file, you also need to import @remix-run/server-runtime. The following is in a global.d.ts file:
import "@remix-run/server-runtime";

declare module "@remix-run/server-runtime" {
  interface AppLoadContext {
   key: "value "
  }
}

I can then run the following in an index.tsx:
import type { LoaderFunction } from "@remix-run/cloudflare"

And everything is typed correctly. (Well, this change also makes context optional, which wasn’t necessarily the case in the past—does this mean I should be checking for its existence, or is it safe to assert that it’s present?)

If anyone is visiting this issue after banging your head against the wall, if you choose to keep the module augmentation in a separate file, you also need to import @remix-run/server-runtime. The following is in a global.d.ts file:

import "@remix-run/server-runtime";

declare module "@remix-run/server-runtime" {

  interface AppLoadContext {

   key: "value"

  }

}

(You may also replace @remix-run/server-runtime with @remix-run/{adapter} if you import your loader function type declaration from the adapter package). I can then run the following in an index.tsx:

import type { LoaderFunction } from "@remix-run/cloudflare"

And everything is typed correctly. (Well, this change also makes context optional, which wasn’t necessarily the case in the past—does this mean I should be checking for its existence, or is it safe to assert that it’s present?)

I'm trying to address the optional issue here: https://github.com/remix-run/remix/pull/3989


verify installation with qemu only

https://rust-embedded.github.io/book/intro/tooling.html#qemu-system-arm
Thanks to this you can follow some parts of this book even if you don't have any hardware with you!
It's not clear what to do here https://rust-embedded.github.io/book/intro/install/verify.html
when just following the book with qemu only.
Suggestion 1:
Skip this section when you don't have hardware
Suggestion 2:
provide some commands to check the tooling without hardware

i can't move this issue forward on my own at the moment

Hi @flip111,
I first thought so too.
But after continuing of reading the next chapters, the book explains the way how to simulate and debug the code with qemu (see chapter "2.1 qemu" https://doc.rust-lang.org/stable/embedded-book/start/qemu.html). Only the chapter "2.2 Hardware https://doc.rust-lang.org/stable/embedded-book/start/hardware.html" isn't possible without proper hardware.
So have fun with the embedded rust stuff.
Cheers,
Heavy


Please correct the procedure of configuring SSO on BP side - it's documented, and support rarely need to help our users

How to configure Azure SSO in BP:
https://help.brightpattern.com/latest:Tutorials-for-admins/Integrations/MicrosoftAzureAD#Configuration_in_Bright_Pattern
Our support rarely needs to help our customers with SSO configuration, most just follow the guide linked above

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

ID: eaeafdb8-f0f9-b6de-009c-bf98df1f010f
Version Independent ID: 455bb4e4-42de-62d1-63b2-1ac228ba5956
Content: Tutorial: Microsoft Entra single sign-on (SSO) integration with Bright Pattern Omnichannel Contact Center - Microsoft Entra ID
Content Source: docs/identity/saas-apps/bright-pattern-omnichannel-contact-center-tutorial.md
Service: entra-id
Sub-service: saas-apps
GitHub Login: @jeevansd
Microsoft Alias: jeedes

@sergem155
Thanks for your feedback! We will investigate and update as appropriate.

@sergem155, we're updating tutorial according to the support article content, you can expect the changes within 3-4 working days.
#please-close


nix-prefetch-svn may return wrong hash due to keyword substitution

Describe the bug
nix-prefetch-svn may calculate hash differently from fetchsvn if the target svn repository uses keyword substitution. In particular, nix-prefetch-svn apparently substitutes $Date$ using local time zone, however (sandboxed) nix-build uses UTC, which results in different date strings, and hence hashes.
To Reproduce
Steps to reproduce the behavior:
test.nix (copied from ctags package):
let
  nixpkgs = import <nixpkgs> {};
in with nixpkgs;
fetchsvn {
  url = "https://svn.code.sf.net/p/ctags/code/trunk";
  rev = "816";
  sha256 = "0jmbkrmscbl64j71qffcc39x005jrmphx8kirs1g2ws44wil39hf";
}

nix-build test.nix --no-link --check agrees with the hash.
nix-prefetch-svn https://svn.code.sf.net/p/ctags/code/trunk 816 reports different hash on my machine 0g9pgnrawf10c26y0xn832skf2ff30scdk3gj12ky0lhg1sa9bfm.
Expected behavior
nix-prefetch-svn should return the same hash as fetchsvn expects.
Additional context
In this example the difference is due to $Date$ substitution performed differently by fetchsvn and by nix-prefetch-svn. Excerpt from the diff between store dirs returned by nix-build and nix-prefetch-svn:
diff -r -U3 /nix/store/dvrx54bbzkjjrgb14gk6pq4g1j5xy6hw-code-r816/Eiffel/external_addressing.e /nix/store/ix0i60ah9r07vf60l94cgbfd20lg728w-code-r816/Eiffel/external_addressing.e
--- /nix/store/dvrx54bbzkjjrgb14gk6pq4g1j5xy6hw-code-r816/Eiffel/external_addressing.e  1970-01-01 03:00:01.000000000 +0300
+++ /nix/store/ix0i60ah9r07vf60l94cgbfd20lg728w-code-r816/Eiffel/external_addressing.e  1970-01-01 03:00:01.000000000 +0300
@@ -2,7 +2,7 @@

        description: "Compiler-dependent external addressing of objects"
        revision: "$Revision: 189 $"
-       date: "$Date: 2002-08-26 03:16:52 +0000 (Mon, 26 Aug 2002) $"
+       date: "$Date: 2002-08-26 07:16:52 +0400 (Mon, 26 Aug 2002) $"
        copyright: "Copyright 2002 Darren Hiebert and others"
        license: "Eiffel Forum License, version 1"

diff -r -U3 /nix/store/dvrx54bbzkjjrgb14gk6pq4g1j5xy6hw-code-r816/Eiffel/tag_entry.e /nix/store/ix0i60ah9r07vf60l94cgbfd20lg728w-code-r816/Eiffel/tag_entry.e
--- /nix/store/dvrx54bbzkjjrgb14gk6pq4g1j5xy6hw-code-r816/Eiffel/tag_entry.e    1970-01-01 03:00:01.000000000 +0300
+++ /nix/store/ix0i60ah9r07vf60l94cgbfd20lg728w-code-r816/Eiffel/tag_entry.e    1970-01-01 03:00:01.000000000 +0300
@@ -2,7 +2,7 @@

        description: "Describes a single entry in a tag file."
        revision: "$Revision: 195 $"
-       date: "$Date: 2002-08-28 04:49:14 +0000 (Wed, 28 Aug 2002) $"
+       date: "$Date: 2002-08-28 08:49:14 +0400 (Wed, 28 Aug 2002) $"
        copyright: "Copyright 2002 Darren Hiebert and others"
        license: "Eiffel Forum License, version 1"

diff -r -U3 /nix/store/dvrx54bbzkjjrgb14gk6pq4g1j5xy6hw-code-r816/Eiffel/tag_extension_fields.e /nix/store/ix0i60ah9r07vf60l94cgbfd20lg728w-code-r816/Eiffel/tag_extension_fields.e
--- /nix/store/dvrx54bbzkjjrgb14gk6pq4g1j5xy6hw-code-r816/Eiffel/tag_extension_fields.e 1970-01-01 03:00:01.000000000 +0300
+++ /nix/store/ix0i60ah9r07vf60l94cgbfd20lg728w-code-r816/Eiffel/tag_extension_fields.e 1970-01-01 03:00:01.000000000 +0300
@@ -2,7 +2,7 @@

        description: "Variable extension fields for tag file entry."
        revision: "$Revision: 189 $"
-       date: "$Date: 2002-08-26 03:16:52 +0000 (Mon, 26 Aug 2002) $"
+       date: "$Date: 2002-08-26 07:16:52 +0400 (Mon, 26 Aug 2002) $"
        copyright: "Copyright 2002 Darren Hiebert and others"
        license: "Eiffel Forum License, version 1"

...

So at the very least, it seems that nix-prefetch-svn should use UTC for expanding $Date$.
Note I am not very familiar with Subversion and didn't even know about keyword substitution until today. I guess the problem may be bigger than just $Date$.
This was discovered while debugging my (invalid) PR https://github.com/NixOS/nixpkgs/pull/101590.
Notify maintainers

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 5.8.14-arch1-1, Arch Linux, noversion`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.3.7`
 - channels(quyse): `""`
 - channels(root): `"nixpkgs-21.03pre246624.cfed29bfcb2"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixpkgs`

Maintainer information:
# a list of nixpkgs attributes affected by the problem
attribute:
# a list of nixos modules affected by the problem
module:

Just adding that setting TZ env var to UTC indeed fixes this particular problem on my machine:
$ TZ=/usr/share/zoneinfo/UTC nix-prefetch-svn https://svn.code.sf.net/p/ctags/code/trunk 816
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is en_US.UTF-8
svn: warning: please check that your locale name is correct
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is en_US.UTF-8
svn: warning: please check that your locale name is correct
svn revision is 816
hash is 0jmbkrmscbl64j71qffcc39x005jrmphx8kirs1g2ws44wil39hf
path is /nix/store/dvrx54bbzkjjrgb14gk6pq4g1j5xy6hw-code-r816
0jmbkrmscbl64j71qffcc39x005jrmphx8kirs1g2ws44wil39hf


Allow importing SamplerV1 and EstimatorV1

Right now, users can't import qiskit_ibm_runtime.SamplerV1 and qiskit_ibm_runtime.EstimatorV1 because we only expose the aliases Sampler and Estimator. That gets in the way of users being explicit about which primitive version they're using.
This also is resulting in the API docs not including the pages for both the V1 and V2 primitives in https://github.com/Qiskit/documentation/pull/973 because we didn't tell autosummary about them.

@kt474 @jyu00 note that this is an actual user API change. You may want to do a patch release today with this fix.


Migrate from hive to hive_ce

Problem Statement
hive_ce is a fork of hive that adds WASM support and it's more up to date then the current stable hive version. It would also avoid having to add more dependencies since hive v4 is based on isar and requires isar_flutter_libs
Solution Brainstorm
Migrating from hive to hive_ce seems to just be replacing hive with hive_ce in imports
# old dependencies
dependencies:
  hive: ^2.0.0
  hive_flutter: ^1.0.0

dev_dependencies:
  hive_generator: ^1.0.0

# new dependencies
dependencies:
  hive_ce: latest
  hive_ce_flutter: latest

dev_dependencies:
  hive_ce_generator: latest

// old imports
import 'package:hive/hive.dart';
import 'package:hive_flutter/hive_flutter.dart';

// new imports
import 'package:hive_ce/hive.dart';
import 'package:hive_ce_flutter/hive_flutter.dart';

Are you willing to submit a PR?
Yes

Today, hive is still a much more popular package (just judging from the limited information available on pub.dev.
Also, it's very easy for the hive_ce users to use to override the dependency using dependency_overrides.
Related to https://github.com/getsentry/sentry-dart/pull/2297 for another package from the same developer. In that PR I've suggested updating docs in the fork to instruct users to use the dependency override.
I don't believe it's desirable for the majority of users to do this change at the moment because it would break all existing hive users using using Sentry SDK, requiring them to change the dependency. Future will tell which package takes over the user-base and we should revisit this decision later.

Maintainer of hive_ce here. Hive is more popular because it has existed for 5 years, while my fork has only existed for 6 months. However, the last update for Hive was over 2 years ago, while my fork is actively maintained. The original Hive does not support WASM compilation, which is a big blocker for a lot of people and the main reason I created hive_ce.
It is not possible to use dependency overrides to replace hive with hive_ce in a project since the packages have different names.
Also, switching to hive_ce is not a breaking change. It looks like sentry_hive wraps the hive implementation, so how would migrating to hive_ce be breaking?

It would be breaking a breaking change to all users using sentry_hive, because after updating, they'd be required to change their dependency from hive to hive_ce

I made a mapping package to allow overriding hive with hive_ce. You can see how to use it in the Hive CE README: https://pub.dev/packages/hive_ce#workaround-for-transitive-hive-dependencies


Framework7 Smart select call page init of second page. How can i stop that.

This is a (multiple allowed):

[x] bug

[ ] enhancement

[x] feature-discussion (RFC)

Framework7 Version: EXACT RELEASE VERSION OR COMMIT HASH, HERE.

Live Link or JSFiddle: PREFERABLY (IF YOU WANT YOUR ISSUE TO BE RESOLVED ASAP). You can start from forking the following JSFiddle template: JSFiddle

What you did
EXPLAIN WHAT YOU DID, PREFERABLY WITH CODE EXAMPLES, HERE.
Expected Behavior
EXPLAIN WHAT IS TO BE EXPECTED, HERE.
Actual Behavior
EXPLAIN WHAT IS ACTUALLY HAPPENING, HERE.
P.S. Remember, an issue is not the place to ask questions. You can use Stack Overflow
for that or join the #framework7 channel on irc.freenode.net, where we will be more
than happy to help answer your questions.
Before you open an issue, please check if a similar issue already exists or has been closed before.

You are saying that it's a feature but i want to not use this feature with any cost. I want to stop this. I have a search page and with each smart select data is populated in the background which makes my application slow. And Cache, speed and results duplication issues.

Your issue is closed because it is not filled correctly. Before you open an issue please review the contributing guideline.
Please fill the issue template correctly and:

Clearly describe the issue including steps to reproduce when it is a bug.
Make sure you fill in the earliest version that you know has the issue.
Provide live link or JSFiddle/Codepen or website with isssue

It will save a lot of time for other contributors to check your issue and fix it.


CFP: hubble: send server version on gRPC calls

Cilium Feature Proposal
Have the Hubble server send its version to Hubble clients, so they may adapt their behaviour.
Is your proposed feature related to a problem?
Some Hubble changes inevitably introduce small breaking changes. For some of theses changes, the client could send a different query depending on the server version.
Currently, there is no way for a client to know the server version (except through the ServerStatus gRPC call), and consequently the client cannot adapt the queries depending on the server version. See this discussion for more context.
Describe the feature you'd like
There should be a way for a Hubble client to get the server version on connection.
(Optional) Describe your proposed solution
Have the Hubble server send the Cilium version through gRPC metadata (e.g. a custom header) on connection.

/assign

Hi, I would like to work on this issue. Could you assign it to me?

@husnialhamdani are you working on this or should we re-assign it to @mantosh-mariner?


Fails in Python3

This doesn't work in Python 3, check this out:
https://travis-ci.org/planetarypy/planetary_test_data/jobs/70276185
Don't forget, before you push your branch, you should be running make test-all.

Im having trouble running make test-all. I keep getting this error:
error: Operation not permitted
ERROR: FAIL could not package project - v = InvocationError('/home/pbvarga1/Workspace/planetary_test_data/venv_osx/bin/python /home/pbvarga1/Workspace/planetary_test_data/setup.py sdist --formats=zip --dist-dir /home/pbvarga1/Workspace/planetary_test_data/.tox/dist (see /home/pbvarga1/Workspace/planetary_test_data/.tox/log/tox-0.log)', 1)
Any ideas on how to fix?


How to read features values which exist in multiple sources?

We need to be able to read specific features enabled/disabled value from multiple places simultaneously, e.g. a feature can be enabled in a database, and disabled in another.
The only possible way to do this I found is to implement a custom class inheriting from FeatureManager, yet I did not find a way in the AddFeatureManagement() configuration to specify a custom class for the IFeatureManager interface.

I would expect dynamic evaluation of features to be implemented through the use of IFeatureFilter. What is preventing that? If it's the fact that the feature definitions themselves need to be read/registered dynamically, then IFeatureDefinitionProvider is also available to implement.

Issue hasn't had any updates. Please feel free to ping if there's still any concerns.


singlediode is slow

The single diode is taking milliseconds on my mac os x i5, and the i_mp, v_mp, and p_mp are very slightly off from the correct values.
There is another method from "Computer simulation of the effects of electrical mismatches in photovoltaic cell interconnection circuits" JW Bishop, Solar Cell (1988)
When I implement this method, the results are more accurate and about 15x to 30x faster!. Also, the pmp is higher, and cross-checking using pvs_imp = i_from_v(vmp) and vmp = v_from_i(imp) shows that the faster method is actually more accurate and still consistent with the old method.
Here are results from test_way_faster.py that compares values using assertions and also measures speed in just one loop:

In [1]: %run pvlib/test/test_way_faster.py
DEBUG:__main__:single diode elapsed time = 0.108363[s]
DEBUG:__main__:way faster elapsed time = 0.000411[s]
DEBUG:__main__:spr_e20_327 speedup = 263.657             <-- first one is much slower :(
DEBUG:__main__:single diode elapsed time = 0.007208[s]
DEBUG:__main__:way faster elapsed time = 0.000314[s]
DEBUG:__main__:fs_495 speedup = 22.9554

In [2]: %run pvlib/test/test_way_faster.py
DEBUG:__main__:single diode elapsed time = 0.00827[s]
DEBUG:__main__:way faster elapsed time = 0.000384[s]
DEBUG:__main__:spr_e20_327 speedup = 21.5365
DEBUG:__main__:single diode elapsed time = 0.008368[s]
DEBUG:__main__:way faster elapsed time = 0.000252[s]
DEBUG:__main__:fs_495 speedup = 33.2063

In [3]: %run pvlib/test/test_way_faster.py
DEBUG:__main__:single diode elapsed time = 0.006553[s]
DEBUG:__main__:way faster elapsed time = 0.000386[s]
DEBUG:__main__:spr_e20_327 speedup = 16.9767
DEBUG:__main__:single diode elapsed time = 0.00638[s]
DEBUG:__main__:way faster elapsed time = 0.000386[s]
DEBUG:__main__:fs_495 speedup = 16.5285

In [4]: %run pvlib/test/test_way_faster.py
DEBUG:__main__:single diode elapsed time = 0.006512[s]
DEBUG:__main__:way faster elapsed time = 0.000348[s]
DEBUG:__main__:spr_e20_327 speedup = 18.7126
DEBUG:__main__:single diode elapsed time = 0.010524[s]
DEBUG:__main__:way faster elapsed time = 0.000345[s]
DEBUG:__main__:fs_495 speedup = 30.5043

In [5]: %run pvlib/test/test_way_faster.py
DEBUG:__main__:single diode elapsed time = 0.00794[s]
DEBUG:__main__:way faster elapsed time = 0.0003[s]
DEBUG:__main__:spr_e20_327 speedup = 26.4667
DEBUG:__main__:single diode elapsed time = 0.007225[s]
DEBUG:__main__:way faster elapsed time = 0.000256[s]
DEBUG:__main__:fs_495 speedup = 28.2227

FYI: I believe SciPy PR 8357 has satisfied all of the reviewers comments, and is hopefully about to be merged. If you are still interested, now might be a good time to show your support for a vectorized Newton method.


Why only for composer.json?

If you can validate a JSON schema with this, why is the plugin limited to files named "composer.json"?
Why not enable it to work with any json-file and use the $schema key to enable support for composer.json or any other json-file with schema?
Just wondering :-)

This plugin is not limited only to validate jsons, it also provide inspections and stuff that is specific for composer. But yes, good point :) On my todo list is support for other package managers, like bower.json, package.json etc. I don't know when it will come because composer is a priority :) Json schema reader in this plugin is very limited and does not support full json schema specification, has some additional composer specific features etc, so more changes are required.

I'm pretty sure you could find a full JSON schema validator as a third-party library?
Anyway, I'm sure pressure on JetBrains to officially support JSON schema will be increasing :-)

Intellij 16 and PhpStorm 11 will have brought us support for json schema :)


Update 04-Creating-Updating-Delete-Queries.ipynb

Issue #, if available: N/A
Description of changes: Example is trying to show how you can remove a property (age, which was just added in the previous step) by setting it to null, but the example is currently setting the entire node to null, which errors out.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

No problem!


Remove FullCLR code

This project started as a fork of the Windows PowerShell 5.1 code base.  As we've progressed towards a PowerShell Core 6.0 release and with the capability of dotnet core 2.0 and dotnet std 2.0 being able to load dotnet framework 4.5.1+ assemblies that are compatible with dotnet std 2.0, we can simplify the code base by removing the legacy FullCLR code so that we no longer have #ifdefs for CORECLR (and !CORECLR).  This was discussed and approved by @PowerShell/powershell-committee

Could we save the code history in a reference branch? It can help with backward compatibility issues.

What is a plan - one PR from MSFT or multiple PRs from community too?

I found #if V2 in src\System.Management.Automation\minishell\api\RunspaceConfiguration.cs 😕

#3565 is related.  I reviewed CORECLR (and !CORECLR) - most of these relate with moving to .Net 2.0 - assembly load, ApartmentState/STA, unimplemented classes/methods/properties in .Net 1.0 and so on. Sometimes it's hard to distinguish. So it's probably easier to clean up the file by file.

Agree that we should divide up this work as multiple PRs from multiple people.  Since we're formally deprecated v2, we should clean up that code as well.

Thanks for clarify!
I am trying to clean up ClrFacade.cs and see all mentioned cases. I can fix simple cases but leave  AprtmentState and assemblies to you :-) - I believe the full cleanup require a huge work and I save your time if make obvious cleanups?

As I'm making other changes, I'm removing legacy code if I see it.

@iSazonov yes, please make obvious cleanups as you see them. But please try to keep each PR small so that we don't miss anything in the code review :)

@SteveL-MSFT cmdlets like Enable-PSRemoting and Disable-PSRemoting contain a lot of scripts that deal with Windows PowerShell, shall we also clean up those scripts?

@daxian-dbw yes

Note that if there is a module that we would eventually split out and publish separately on PSGallery.  That module should support Windows PowerShell (in general) and would retain FullCLR code (don't know if they have specific code paths, but Archive and ODataUtils would be examples)

@daxian-dbw  @adityapatwardhan Thanks for fast reviews!
We have many '#if CORE' for "assemlies" and hude for STA/apartment. Also we should review code base on .Net Core 1.0 -> 2.0 enhancements. I think it is better to make explicit points in #3565 for that and close the Issue.

#3565 is more about reviewing '#if UNIX' blocks, while this one is focused on '#if CORECLR' blocks.
I think it's better to separate these two depending on how the cleanup work is being done. Someone probably wants to focus on removing the dead Full CLR code, so he/she can leave the related #if UNIX block untouched without worrying that the change will cause a regression in Unix plats.

I'm in process of taking care of ApartmentState

Who we can ask to clean up web cmdlets?

We should continue to clean up the code, but it's not a blocker for 6.0.0 release

I've gone and surveyed the remaining usages of the CORECLR compilation guard, and I'll try and break it down here.
Thread model changes

[ ] CommonUtils.cs uses FullCLR threads.
[ ] Stubs.cs is entirely CoreCLR specific and uses System.ComponentModel -- I assume it's a FullCLR polyfill.
[ ] Connection.cs also uses transactions in FullCLR.
[ ] ControlFlowInstructions.cs uses Thread.Abort and ThreadAbortException here.
[ ] Attributes.cs has SupportsTransactions not supported in CoreCLR, since CoreCLR does not support System.Transactions.
[ ] remoterunspace.cs also uses a worker thread in FullCLR.
[ ] throttlemanager.cs uses Thread.Abort() in FullCLR.
[ ] RegistryProvider.cs makes the provider capability transactional.

ApartmentState usage

[ ] Connection.cs uses ApartmentState in FullCLR only.
[ ] new-object.cs uses thread apartments for COM handling.
[ ] ConnectionBase.cs uses ApartmentState in FullCLR here and here, as well as ApartmentState.STA here.
[ ] LocalPipeline.cs uses ApartmentState here and here, as well as ThreadAbortException here.
[ ] PowerShell.cs uses ApartmentState here, here, here, here, here, here and here.
[ ] RunspacePool.cs uses ApartmentState here.
[ ] RunspacePoolInternal.cs uses ApartmentState here, here and here.
[ ] InternalSessionState.cs uses ApartmentState here and here.
[ ] LocalConnection.cs uses ApartmentState.STA here and another ApartmentState reference here.
[ ] CustomShellCommands.cs uses ApartmentState here, here, here, and here.
[ ] RunspaceConnectionInfo.cs uses ApartmentState manipulation in FullCLR.
[ ] EncodeAndDecode.cs uses RunspacePool.ApartmentState here, here, here and here.
[ ] InitialSessionStateProvider.cs references ApartmentState here, here and here.
[ ] remoterunspace.cs uses ApartmentState here.
[ ] ServerPowerShellDriver.cs uses ApartmentState here, here, here, here and here.
[ ] serverremotesession.cs uses ApartmentState here and here.
[ ] ServerRunspacePoolDriver.cs has ApartmentState references here, here, here, here, here, here, here, here, here, here, here, here and here.
[ ] ServerSteppablePipelineDriver.cs uses ApartmentState here, here and here.

AppDomain usage

[ ] ExecutionContext.cs only uses AppDomains in FullCLR, here and here.
[ ] LanguagePrimitives.cs uses AppDomains here and here.
[ ] ModuleCmdletBase.cs has a single-AppDomain-specific function for CoreCLR only.
[ ] RemoteSession.cs uses AppDomains here, here and here.
[ ] WSManPlugin.cs manages AppDomains here and here.
[ ] WSManPluginFacade.cs uses AppDomains for LongPath support in FullCLR.
[ ] OutOfProcServerMediator.cs uses AppDomains here, here and here.
[ ] SecuritySupport.cs has an AppDomain reference.

Workflow usage

[ ] CommandCommandParameters.cs has CommonWorkflowParameterTypes defined only in FullCLR, since workflows are not supported on CSS.
[ ] debugger.cs uses Workflows in FullCLR only here, here, here, here, here, here, here and here.
[ ] ModuleCmdletBase.cs has workflow-specific code here, here and here.

CIM/PSMI/WMIv1/DirectoryServices usage

[ ] Command.cs has PSMI not supported on CSS.
[ ] Parameter.cs only has ToCimInstance in FullCLR, noting that PSMI is not supported on CSS.
[ ] PowerShell.cs also has PSMI/FullCLR code here and here.
[ ] MshObject.cs has WMI adapters here and here.
[ ] LanguagePrimitives.cs uses System.DirectoryServices and  ManagementObject, ManagementObjectSearcher, ManagementClass, CommaDelimitedStringCollection, DirectoryEntry, caching them here. Extra CommaSeparatedStringCollection here.
[ ] MshObject uses System.DirectoryServices.

Reflective execution on internal types

[ ] CoreAdapter.cs has three places (1, 2, 3) where it does extra work since reflective execution can be prevented in .NET Core. The helper functions are located here.
[ ] LanguagePrimitives.cs here
[ ] Binders.cs runs this check.

FullCLR culture API usage

[ ] LocalPipeline.cs uses Thread.CurrentCulture.
[ ] WsManHelper.cs also uses CultureInfo.CurrentUICulture.LCID in FullCLR, but a hardcoded WinRM path in CoreCLR.
[ ] InternalHost.cs uses FullCLR culture APIs here.
[ ] GetCounterCommand.cs uses Thread.CurrentThread.CurrentUICulture to check the culture in FullCLR.
[ ] ModuleUtils.cs uses CultureInfo.LCID to check module directories in FullCLR.
[ ] OutOfProcServerMediator.cs uses Thread.CurrentUICulture.

Snap-ins

[ ] InternalSessionState.cs has CustomPSSnapIn support in FullCLR only, here and here.
[ ] ModuleCmdletBase.cs only warns about importing snap-ins with Import-Module in FullCLR.
[ ] MshSnapinInfo.cs only supports CustomPSSnapIns in FullCLR.

Impersonation/security contexts

[ ] MshCommandRuntime.cs uses SecurityContexts here, here and here.
[ ] LocalPipeline.cs uses impersonation in FullCLR only. Also in the finally block
[ ] pipeline.cs has impersonation code here and here.
[ ] BaseTransportManager.cs impersonates to process callbacks.
[ ] WSManTransportManager.cs uses impersonation here, here, here and here.
[ ] OutOfProcServerMediator.cs uses impersonating thread queuing.
[ ] ServerRunspacePoolDriver.cs impersonates here and here.
[ ] Utils.cs has some impersonation logic

Global Assembly Cache

[ ] Compiler.cs resolves assemblies in the GAC in FullCLR.
[ ] FusionAssemblyIdentity.cs is entirely FullCLR-specific.
[ ] GlobalAssemblyCache.cs is also like this.
[ ] Parser.cs also searches the GAC.

XML Parsing

[ ] BaseTransportManager.cs sets a null XmlResolver on an XmlReader.
[ ] NewWinEventCommand.cs adds XmlResolver = null to an XmlReader instantiation.
[ ] CredSSP.cs uses XPath in CoreCLR.
[ ] WsManHelper.cs uses XPath in CoreCLR only.
[ ] InitialSessionStateProvider.cs uses the XmlResolver parameter.
[ ] UpdatableHelpSystem.cs uses a ValidationEventHandler (here as well), uses different XML parsing code, and uses a schema.

ETW

[ ] ExecutionPolicyCommands.cs seems to use ETW logging APIs in FullCLR-specific code
[ ] UpdatableHelpCommandBase.cs has code supposed to be added to CoreCLR when ETW is supported.

Other types and methods not supported in CoreCLR

[ ] GetCounterCommand.cs doesn't have an overload of EventWaitHandle.WaitOne that we use in FullCLR.
[ ] AssemblyInfo.cs uses ConstrainedExecution
[ ] Extensions.cs uses a different way to change a SecureString to a string in FullCLR.
[ ] AclCommands.cs only supports GetAllCentralAccessPolicies and GetCentralAccessPolicyName in FullCLR (explained here). Also the CentralAccessPolicy parameter.
[ ] Introp.cs uses IUnknown in CoreCLR and IDispatch in FullCLR here, here, here, here, here, here, here, here, here, here, here, here, here, here, here and here. There are also CoreCLR-specific uses of IUnknown here, here, here, here, here, here and here.
[ ] EventManager.cs uses StackFrame and SymbolStore in FullCLR but can't in CoreCLR. Affected code is here, here, here, here, here, here, here, here.
[ ] Parser.cs uses Microsoft.CodeAnalysis.
[ ] TypeResolver.cs does a ClrFacade lookup in CoreCLR only.
[ ] TypeResolver.cs also caches some FullCLR types.
[ ] EncodeAndDecode.cs uses TimeZone.
[ ] BaseTransportManager.cs uses System.Security.Principal.
[ ] WSManTransportManager.cs uses System.Security.Principal.
[ ] Types_Ps1Xml.cs excludes FullCLR-only types here and here.
[ ] UpdatableHelpCommandBase.cs catches WebExceptions in FullCLR only, here and here.
[ ] UpdatableHelpSystem.cs uses System.IO.Compression, System.Net.Http and System.Threading.Tasks in CoreCLR and System.Xml.Schema in FullCLR here.
[ ] UpdatableHelpSystem.cs uses AutoResetEvent and not TimeSpan here, here, here, here and here.
[ ] UpdatableHelpSystem.cs also uses extra WebClient features in FullCLR here, here, here, here, here and here.
[ ] ClrFacade.cs indicates that System.Runtime.Remoting may be present on FullCLR.
[ ] ClrFacade.cs implements a polyfill for ManagementDateTimeConverter.ToDmtfDateTime.

Windows-specific FullCLR code

[ ] CommonUtils.cs seems to load some FullCLR-specific Windows kernel assemblies (which CoreCLR has an alternative for).
[ ] ExportCounterCommand.cs does a Windows 7 check before instantiating a PdhHelper.
[ ] GetCounterCommand.cs also checks for Windows 7 before instantiating a PdhHelper.
[ ] ImportCounterCommand.cs also does the Windows 7 check before instantiating the PdhHelper.
[ ] Sam.cs goes to a lot of effort in CoreCLR to workout what operating system is running. FullCLR just queries the Windows environment.
[ ] ExecutionPolicyCommands.cs uses Windows specific APIs to work out if execution is occurring interactively in FullCLR.
[ ] CredSSP.cs uses Windows APIs to query to OS version here, here and here.
[ ] CredSSP.cs also uses an extra argument for a registry API here and here
[ ] WsManHelper.cs uses the extra argument for a registry API here and here
[ ] CommandDiscovery.cs closes a progress pane in FullCLR only.
[ ] GetEvent_Types_Ps1Xml.cs only includes GetCounter members in FullCLR
[ ] CustomShellCommands.cs does some system32 folder handling in FullCLR when CoreCLR throws an error.
[ ] EnterPSHostProcessCommand.cs has a main window title property in FullCLR, which it sets by querying the process information.
[ ] CertificateProvider.cs has a GetOwnerWindow method that seems to return a zero IntPtr and only exists in CoreCLR.
[ ] UpdateHelpCommand.cs checks for side-by-side directories in FullCLR.
[ ] FileSystemProvider.cs has some extern methods that pull in Windows assemblies in CoreCLR here. In FullCLR, kernel.dll is used here and some file system APIs are used here.
[ ] Win32Native.cs has a large FullCLR-specific region.

PSReadLine

[ ] KillYank has a few places where I think it's using a FullCLR API for the Windows clipboard:

A System.Windows.Forms reference.
Pasting
Copying
Cutting
Note that the upstream PSReadline codebase no longer contains these references.

[ ] ReadLine.cs has multiple AppDomain support in FullCLR.
[ ] ReadLine.cs also has some STAThread support specifically in FullCLR.

Again note that these have been removed upstream

[ ] ScreenCapture.cs also Windows clipboard code in FullCLR, which again is no longer in the upstream ReadLine code
[ ] InternalHost.cs also uses StackFrame in FullCLR here.

PowerShell native

[ ] NativeMsh.h includes mscoree.h in FullCLR. There is a dependency on .NET 1.0 in FullCLR, which the comment explains can be dropped if we move from using ICorRuntimeHost to using ICLRRuntimeHost.
[ ] pwshcommon.cpp also has the dependency on the deprecated .NET 1.0 types in FullCLR.
[ ] CssMainEntry.cpp also conditionally includes mscoree.h.
[ ] OutputWriter.h uses LoadMUILibraryW to load a language neutral culture handle, where CoreCLR uses LoadLibraryEx.
[ ] entrypoints.cpp conditionally includes muiload.h in FullCLR and also uses LoadMUILibraryW.
[ ] pwshclrhost.cpp conditionally imports mscorlib.tlb for AppDomain access using COM. It defines a different set of PowerShellClrWorker methods in CoreCLR and FullCLR, as well as different factory method.
[ ] pwshclrhost.h conditionally includes mscoree.h. In FullCLR it defines PowerShellClrWorker rather than PowerShellCoreClrWorker. There is a note to refer back to the note about .NET 1.0 dependencies in NativeMsh.h.

Miscellaneous

[ ] new-object.cs does some !CORECLR-wrapped COM handling, but I'm not entirely sure why it's FullCLR-specific.
[ ] AssemblyInfo.cs sets some assembly attributes in FullCLR only.
[ ] ScriptWriter.cs is set to ignore DTD parsing in CoreCLR and perform it in FullCLR, due to cmdlets-over-objects.xsd being missing in GitHub (according to the comment).
[ ] cmdlets-over-objects.cs only exists in CoreCLR
[ ] CorePsAssemblyLoadContext.cs only exists in CoreCLR
[ ] CimDscParser says that configurations are not supported in PowerShell Core. The method CurrentDomain_ReflectionOnlyAssemblyResolve is only defined in FullCLR.
[ ] CommandMetadata.cs only has GetRestrictedJobCommands in FullCLR, with the comment "Not referenced on CSS".
[ ] HostUtilities.cs just returns false in CoreCLR for HostUtilities.IsProcessInteractive, whereas it does real checks in FullCLR.
[ ] PowerShellProcessInstance uses extra version parameters to start PowerShell in FullCLR
[ ] InternalSessionState.cs also has FullCLR-only aliases here, here and here.
[ ] ModuleCmdletBase.cs checks the CLR version in FullCLR, as well as the .NET Framework version
[ ] CustomShellCommands.cs throws because PowerShell 2.0 is not on CoreCLR.
[ ] ResumeJob.cs only uses certain annotations in FullCLR.
[ ] SuspendJob.cs also on uses certain annotations in FullCLR.
[ ] serialization.cs uses .NET serialization in FullCLR.
[ ] HelpSystem.cs only adds a DSC resource help provider in FullCLR.
[ ] UpdatableHelpSystem.cs has a FullCLR-only constructor for UpdatableHelpSystemException.
[ ] MshLog.cs has a block waiting for EventLogLogProvider in CoreCLR.
[ ] SecureStringHelper.cs have a temporary workaround for CoreCLR while ProtectedData is brought to Project K.
[ ] SecurityManager.cs only has SAFER API support on FullCLR.
[ ] SecuritySupport.cs also has some SAFER-specific code.
[ ] StructuredTraceSource.cs only catches a System.Configuration.ConfigurationException in FullCLR.

@rjmholt Great work! Could you please move your post in new Meta-Issue and add link here?

Note: The CustomPSSnapin class is not even available therefore CustomPSSnapIns is not possible for FullCLR with the open source code given by this repo. I do not think this is an issue therefore the better solution could  be to completely remove PSSnapin related code.

It is not difficult until the code is used in serialization.

@SteveL-MSFT Could you please update a status of the Issue? Seems most was fixed and now it is not clear that we can fix yet.

@iSazonov I made an attempt to see what in the check list is already fixed and what isn't.  The problem is that the hyperlinks go to older commits and don't reflect current state.  Might be easier to write a script to scan the code and generate a new checklist but we won't know what has been fixed, just what needs to be fixed.

I caught the same and thought that you have an idea  - good point about script. We could review "file by file".

param($path = "../repos/PowerShell")

$sources = Get-ChildItem -Recurse -Path $path -Include *.cs
foreach ($source in $sources) {
    $content = Get-Content $source -Raw
    if ($content -match "#if CORECLR" -or $content -match "#if !CORECLR") {
        $source.FullName
    }
}

src/Microsoft.PowerShell.Commands.Diagnostics/CoreCLR/Stubs.cs
src/Microsoft.PowerShell.Commands.Diagnostics/CommonUtils.cs
src/Microsoft.PowerShell.Commands.Diagnostics/ExportCounterCommand.cs
src/Microsoft.PowerShell.Commands.Diagnostics/GetCounterCommand.cs
src/Microsoft.PowerShell.Commands.Diagnostics/ImportCounterCommand.cs
src/Microsoft.PowerShell.Commands.Diagnostics/NewWinEventCommand.cs
src/Microsoft.PowerShell.Commands.Utility/commands/utility/new-object.cs
src/Microsoft.PowerShell.LocalAccounts/LocalAccounts/Extensions.cs
src/Microsoft.PowerShell.LocalAccounts/LocalAccounts/Sam.cs
src/Microsoft.PowerShell.Security/security/AclCommands.cs
src/Microsoft.PowerShell.Security/security/CertificateProvider.cs
src/Microsoft.PowerShell.Security/security/ExecutionPolicyCommands.cs
src/Microsoft.WSMan.Management/CredSSP.cs
src/Microsoft.WSMan.Management/Interop.cs
src/Microsoft.WSMan.Management/WsManHelper.cs
src/System.Management.Automation/cimSupport/cmdletization/xml/CoreCLR/cmdlets-over-objects.xmlSerializer.autogen.cs
src/System.Management.Automation/cimSupport/cmdletization/ScriptWriter.cs
src/System.Management.Automation/CoreCLR/CorePsAssemblyLoadContext.cs
src/System.Management.Automation/DscSupport/CimDSCParser.cs
src/System.Management.Automation/engine/debugger/debugger.cs
src/System.Management.Automation/engine/hostifaces/Command.cs
src/System.Management.Automation/engine/hostifaces/Connection.cs
src/System.Management.Automation/engine/hostifaces/ConnectionBase.cs
src/System.Management.Automation/engine/hostifaces/HostUtilities.cs
src/System.Management.Automation/engine/hostifaces/InternalHost.cs
src/System.Management.Automation/engine/hostifaces/LocalConnection.cs
src/System.Management.Automation/engine/hostifaces/LocalPipeline.cs
src/System.Management.Automation/engine/hostifaces/Parameter.cs
src/System.Management.Automation/engine/hostifaces/PowerShell.cs
src/System.Management.Automation/engine/hostifaces/PowerShellProcessInstance.cs
src/System.Management.Automation/engine/hostifaces/RunspacePool.cs
src/System.Management.Automation/engine/hostifaces/RunspacePoolInternal.cs
src/System.Management.Automation/engine/interpreter/ControlFlowInstructions.cs
src/System.Management.Automation/engine/Modules/ModuleCmdletBase.cs
src/System.Management.Automation/engine/parser/Compiler.cs
src/System.Management.Automation/engine/parser/FusionAssemblyIdentity.cs
src/System.Management.Automation/engine/parser/GlobalAssemblyCache.cs
src/System.Management.Automation/engine/parser/Parser.cs
src/System.Management.Automation/engine/parser/TypeResolver.cs
src/System.Management.Automation/engine/remoting/client/remoterunspace.cs
src/System.Management.Automation/engine/remoting/commands/CustomShellCommands.cs
src/System.Management.Automation/engine/remoting/commands/EnterPSHostProcessCommand.cs
src/System.Management.Automation/engine/remoting/commands/remotingcommandutil.cs
src/System.Management.Automation/engine/remoting/commands/ResumeJob.cs
src/System.Management.Automation/engine/remoting/commands/SuspendJob.cs
src/System.Management.Automation/engine/remoting/common/WireDataFormat/EncodeAndDecode.cs
src/System.Management.Automation/engine/remoting/common/RemoteSessionNamedPipe.cs
src/System.Management.Automation/engine/remoting/common/RunspaceConnectionInfo.cs
src/System.Management.Automation/engine/remoting/common/throttlemanager.cs
src/System.Management.Automation/engine/remoting/fanin/BaseTransportManager.cs
src/System.Management.Automation/engine/remoting/fanin/InitialSessionStateProvider.cs
src/System.Management.Automation/engine/remoting/fanin/WSManPlugin.cs
src/System.Management.Automation/engine/remoting/fanin/WSManPluginFacade.cs
src/System.Management.Automation/engine/remoting/fanin/WSManTransportManager.cs
src/System.Management.Automation/engine/remoting/server/OutOfProcServerMediator.cs
src/System.Management.Automation/engine/remoting/server/ServerPowerShellDriver.cs
src/System.Management.Automation/engine/remoting/server/serverremotesession.cs
src/System.Management.Automation/engine/remoting/server/ServerRunspacePoolDriver.cs
src/System.Management.Automation/engine/remoting/server/ServerSteppablePipelineDriver.cs
src/System.Management.Automation/engine/Attributes.cs
src/System.Management.Automation/engine/CommandDiscovery.cs
src/System.Management.Automation/engine/CommandMetadata.cs
src/System.Management.Automation/engine/ExecutionContext.cs
src/System.Management.Automation/engine/GetEvent_Types_Ps1Xml.cs
src/System.Management.Automation/engine/InitialSessionState.cs
src/System.Management.Automation/engine/LanguagePrimitives.cs
src/System.Management.Automation/engine/MshCommandRuntime.cs
src/System.Management.Automation/engine/pipeline.cs
src/System.Management.Automation/engine/serialization.cs
src/System.Management.Automation/engine/Types_Ps1Xml.cs
src/System.Management.Automation/engine/Utils.cs
src/System.Management.Automation/help/HelpSystem.cs
src/System.Management.Automation/help/UpdatableHelpCommandBase.cs
src/System.Management.Automation/help/UpdatableHelpSystem.cs
src/System.Management.Automation/help/UpdateHelpCommand.cs
src/System.Management.Automation/logging/MshLog.cs
src/System.Management.Automation/namespaces/FileSystemProvider.cs
src/System.Management.Automation/namespaces/RegistryProvider.cs
src/System.Management.Automation/namespaces/Win32Native.cs
src/System.Management.Automation/security/SecureStringHelper.cs
src/System.Management.Automation/singleshell/config/MshSnapinInfo.cs
src/System.Management.Automation/utils/ClrFacade.cs
src/System.Management.Automation/utils/StructuredTraceSource.cs

One thing we should be careful of is not straight removing the FullClr code, but seeing if the Windows PowerShell code now works because of updates to .NET Core.

@SteveL-MSFT Seems we can close the Issue: all #if FullCLR code was removed (I found FullCLR only in comments) and we have #4357 to track updates of .NET Core.

Search results for #if .*CORECLR - 543 results in 186 files.

Now search results for #if .*CORECLR - 174 results in 70 files.


Ability to use markdown for index page

Bug fix:

Fixed bug in serve where assets/prettify/prettify-min.js was not found

Features Added:

Ability to hide version tag in sidebar (was defaulting to 0.0.1 if left blank)
Ability to use a directory with arbitrary markdown files as the homepage docs

Update to README

@dangreenisrael thanks for taking the time in putting this together. I've decided to go a different route. Please check out PR #2 and see if those changes fit your need.

Hey Offir,
That looks great, smart way of doing it.
We still have a few issues though.

We now have a README.js in the root of our project, but at the top of the indexModule page, it says defined in not/theActualFile.js:5, which is a broken link.

We don't have a version tag in our yuidoc.json file, but there is a tag: 0.0.1 in the sidebar which is a broken link.

I'd be happy to address these and make another PR if you like

Dan

I'd be happy to address these and make another PR if you like

@dangreenisrael that would be great thank you! 😄


[WIP] Enable e2e test

What this PR does / why we need it?:
Enable e2e testing of the operator.
Does this PR introduce a user-facing change?
No.
Which issue(s) this PR fixes:
Fixes #218.

One suggestion would be to put the e2e into a separate step after verify-image build and not part of the arch matrix, the reason is that tests might fail but other arch could push  respective arch images regardless.


ajv Override Validation Functions

I have a requirement where I need to Override the String Validation Functions. I can't modify anything in the JSON Schema, as my product is dependant on it.
Example, String can be null, but I can't add isNullable as a key in the JSONSchema as my product is dynamically generating it and using it. Is there a way where we can override the existing String Validation Function to accept String as Null also?? I'm sharing my current implementation.
Kindly help me on this. Excuse for my immaturity in raising this issue as I have some strict deadline to meet.
What version of Ajv are you using? Does the issue happen if you use the latest version?
Latest version
JSON Schema
"OriginalOrderId": {
      "title": "Order ID",
      "description": "Order ID",
      "display": {
        "name": "Original Order ID",
        "description": "Original Order ID",
        "required": false,
        "visible": true,
        "order": 6,
        "tags": [
          "OriginalOrderID",
          "originalorderid"
        ]
      },
      "type": "string"
    }

Sample data

{ "OriginalOrderId": null }

Your code
function validateString(str) {
  return _.isString(str) || str === null
}
ajv.addFormat('int32', validateString, ['string']);

var valid = ajv.validate(newSchema, value);

I am not sure why you are unable to modify the schema - it is a trivial thing to do in your code programmatically by traversing the schema and replacing each type:string with type:[string,null] - you could use JSON-schema-traverse (that ajv uses to traverse the schemas).
In any case, the logic of string validation will not be changed in ajv.

As I had explained earlier, that we are consuming the JSONSchema in an intermediate step and can't modify that. Anyways thanks for this.
In case you find this relevant, and have a way in which we can override existing validation functions , it'll be of great help.


Bloodpacks can be ground for blood

About the PR
Bloodpacks can now be ground for blood. Now if chemists need a bit of blood for a recipe they don't have to grab a syringe and extract it from themselves, they can use bloodpacks. Which from an RP standpoint both seems more sanitary, and makes more sense. I did my best to make it balanced so it's not an excessive amount but also where chem doesn't need to grind every single bloodpack in med. I ended up at
>one bloodpack = 8 blood, 2 saline
>a stack of 10 is 80 blood, 20 saline
Which I think is a good middle ground, though I am welcome to thoughts on this.
Why / Balance
As mentioned before, this makes more sense RP wise.
Technical details
made bloodpacks extractable fluidcontainers
Media
Requirements

[X] I have read and am following the Pull Request and Changelog Guidelines.
[X] I have added media to this PR or it does not require an ingame showcase.

Breaking changes
None. Probably.
Changelog
:cl:

tweak: Bloodpacks now actually contain blood, and can be put in a grinder to extract said blood.

Uses bloodpack - 5% blood.
Grinds bloodpack - 8% blood + tasty proteins. 🤔

Uses bloodpack - 5% blood. Grinds bloodpack - 8% blood + tasty proteins. 🤔

I looked at how much saline does and I'm pretty sure it should be just under the effect of a bloodpack. and you can't actually inject blood to restore blood volume iirc, that just poisons

1u of saline is 4% of blood level for humanoids so 1.25 or bit less would in almost all scenarios make it regain same/less blood level as using the bloodpack which restores static amount of blood level rather than adjusting reagents that make up bloodstream.
Smaller the mob smaller the blood amounts too but you won't be bloodpacking Hammy often to get more blood % out of bloodpack anyways.

1u of saline is 4% of blood level for humanoids so 1.25 or bit less would in almost all scenarios make it regain same/less blood level as using the bloodpack which restores static amount of blood level rather than adjusting reagents that make up bloodstream.
Smaller the mob smaller the blood amounts too but you won't be bloodpacking Hammy often to get more blood % out of bloodpack anyways.

I guess i read it wrong. I'll see what I did and correct that in a bit

Where's the logic in grounding up bloodpacks? Wouldn't it make more sense for blood packs to be a container for the fluid itself, similar to soda cans and the blood pack can be extracted?

Also the contents don't make sense when you consider you can use them safely on arachnids

uhh. suspend disbelief?
I don't have an answer for this.

Plus I just get my blood out of Walter

Animal abuse, I'm calling the space cops!!1!

Where's the logic in grounding up bloodpacks? Wouldn't it make more sense for blood packs to be a container for the fluid itself, similar to soda cans and the blood pack can be extracted? So when you remove the blood pack by unsealing it and removing the liquid you'd be left with a empty IV bag.

Probably, but thats more work and at that point we might as well just copy the way bloodpacks work in RMC

Iron/copper used to be overpowered due to bug, now they are basically desperation reagents to use as it.
Bloodpacks are only way to treat blood damage that pushes some thing or someone into defib range, saline is preferable in almost all other cases unless blood level is so low that in specific scenarios patient can't survive without raising it first, especially spiders that take 50% more choke damage on top of the bleed and only process reagents at 66% speed meaning they can die before medicine have any effect.
Saline is the go to for most other scenarios, 25u get folks to full blood level which fits in a bottle so can be used for field treatment and it does not interrupt heart metabolism so most species can use it together with other 2 reagents healing them.

closing this PR because bloodpacks are (probably) going to be reworked in newmed so :P

Just a week away 😢


Initial tests for snowpack dev

Changes
none
Testing
adds a test for snowpack dev by downloading HTML and built JS and from the dev server and comparing to snapshots.
To run only the new dev test:
npx jest test/dev/dev.test.ts

Docs
no changes

I'm debuging the CI error. The tests do pass locally

ugh sorry it still seems to get stuck on Windows 😓

Note: due to the nature of this test, I wouldn’t mind moving this to its own dev job where we don’t run it on Windows (maybe we only run it on 1 version of Node, too, to start).

This would resolve the problem here. Let me know if that works for you before I put more time into trying to make this work with Windows.

I've disabled the tests from running on Windows. I think it would be good to enable that, we just have to figure out how to properly exit the spawned process.
The current CI errors are unrelated to this PR

I did some more digging. And I see this error, but only when running on windows

[snowpack] cjsAutoDetectExportsStatic error: Unexpected export statement in CJS module.

https://github.com/pikapkg/snowpack/runs/1228515602?check_suite_focus=true#step:4:996
The code was introduced here: https://github.com/pikapkg/snowpack/pull/1163/files#diff-dbf11f54f6a2a639125187af3e3f9d8fR52-R69 @FredKSchott

Hmm I removed the check for loading http://localhost:8080/_dist_/index.js and the warning went away, but snowpack is restarting anyway.
https://github.com/pikapkg/snowpack/runs/1228547337?check_suite_focus=true#step:4:120

Aha! Looks like we need to add snapshot tests for the dev server output as well, to catch things like this.
That's expected logger.debug output though, that reports when a file is already ESM (failing CJS scanning as expected). The plugin is designed to recover from this, so that shouldn't be breaking anything.

Is there logic that makes the dev server restart entirely in some cases?

It would be helpful if someone with a windows environment could test this pull request and see what is happening?
To run only the new test, run
npx jest test/dev/dev.test.ts --test-timeout=30000

/cc @stramel  @gr2m could use your help!

I messed up my local windows environment attempting to switch to WSL2 😭 I will see if I can get everything set back up this weekend

To whomever wants to look into it: I'd suggest to create a separate repository which reproduces the problem with as little code as possible, then we can collaborate on resolving the problem there


Page shows white area when overscrolling

Summary
When scrolling on either mobile or browser, overscrolling at the bottom will show white after the header.
Steps to reproduce

Scroll down to footer and then 'overscroll'.
White is shown.

What is the current bug behavior?
White shown on overscroll
What is the expected correct behavior?
We should consider being consistent with the footer color for 'immersion'.
Relevant logs and/or screenshots

Environment
Any device or machine

How do we feel about fixing this using:
body: {
   overscroll-behavior-y: none;
}

This is the simplest solution but can have some unintended consequences. We don't use pull-to-refresh anywhere do we?

@jmilldotdev  I don't think we use pull-to-refresh anywhere on the page


Fix message relay section issues in docs

Purpose

Fix message builder configurations for message relay
Remove message relay module
Fix broken links

Fix https://github.com/wso2/docs-ei/issues/864

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: madushadhanushka:x: nilminiwso2You have signed the CLA already but the status is still pending? Let us recheck it.


Added icon, changed fonts, etc after group meeting

Implementing additional UI changes as suggested by team.

Very proud of this update to the UI: the user interface is beautiful and the issues with the diagrams from previous updates (the big boxes with a cross) are fixed.


Draft: Noel/runtime docs

In GitLab by @kwanzknoel on Jun 9, 2021, 04:31
Closes #200
Documentation of Glow's runtime.
There are areas where I would like to eventually elaborate on. These are marked with TODOs.
For now I believe this is a good enough starting point.

Ported over to wiki: https://github.com/Glow-Lang/glow/wiki/Internals-Runtime


api: first revision of configuration object

@danwinship This is a real PR for the configuration API. PTAL.
It doesn't have to be perfect, but it should pass the sniff test.


local_storage

I find the local_storage feature to be very useful for caching the filter criteria.
I wonder whether this can be made global?
I have table filters generated every day for the performance testing. Sometimes I find that I want to have the same filter criteria for all tables. So that I can quickly go through all the historical pages with the same search criteria.
If this is not possible - would you recommend doing the following:
var tf = new TableFilter();
if (file exists && read the file on webserver ){
tf.setFilterValue(2, "populate criteria specified from the file");
tf.filter();
}

There is no notion of global caching, filter criteria are stored on a per table-id and URL path basis, the key of a store looks like this:
{"key":"TF_{table-id}","path":"{url-path}l"}

as per https://github.com/koalyptus/TableFilter/blob/master/src/modules/storage.js#L142.
The javascript here runs on the browser, as a result you cannot access the file system of the server...
If you have control over your application, you might consider url hash persistence (hash) instead of local storage. If your tables are in located in different screens/pages/routes you might consider preserving the URL hash in your links so that filter criteria are preserved across pages.

Thanks for the prompt reply.
By URL hash does you mean something like
www.mywebsite.com/mypage1.html?mytableid#col1=value1#col2=value2http://www.mywebsite.com/mypage1.html?mytableid#col1=value1#col2=value2
www.mywebsite.com/mypage2.html?mytableid#col1=value1#col2=value2http://www.mywebsite.com/mypage2.html?mytableid#col1=value1#col2=value2
to automatically set the same criteria values across different pages?
I found the documents for url hash
https://github.com/koalyptus/TableFilter/wiki/1.17-State
I guess I need use the hash.js and to set the following
var tfConfig = { state: { types: ['hash'] };
What parameters do I actually use on the url to achieve this?
BTW: I am on holiday next week – if I get some help with the url hash in the next 9 hours I will try out immediately ☺
From: koalyptus<EMAIL_ADDRESS>Sent: 28 July 2017 05:04
To: koalyptus/TableFilter
Cc: PANG, Wai (CA-CIB); Author
Subject: Re: [koalyptus/TableFilter] local_storage (#491)
There is no notion of global caching, filter criteria are stored on a per table-id and URL path basis, the key of a store looks like this:
{"key":"TF_{table-id}","path":"{url-path}l"}
as per https://github.com/koalyptus/TableFilter/blob/master/src/modules/storage.js#L142.
The javascript here runs on the browser, as a result you cannot access the file system of the server...
If you have control over your application, you might consider url hash persistence (hash) instead of local storage. If your tables are in located in different screens/pages/routes you might consider preserving the URL hash in your links so that filter criteria are preserved across pages.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/koalyptus/TableFilter/issues/491#issuecomment-318553145, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWmyAoqvDyF_rqFhTneUc0KuwEzb__g2ks5sSV3KgaJpZM4OlUym.
Where you have received a communication from CREDIT AGRICOLE CORPORATE AND INVESTMENT BANK this may include information which constitutes an investment recommendation as defined by the European Market Abuse Regulation (MAR).
Please see http://www.ca-cib.com/group-overview/general-disclaimer-sales-trading.htm http://www.ca-cib.com/group-overview/general-disclaimer-sales-trading.htm for important regulatory information in this regard.
If you have any questions in relation to MAR and its impact on your relationship with Credit Agricole Corporate & Investment Bank  please let your salesperson know.
This email does not create a legal relationship between any member of the Crédit Agricole group and the recipient or constitute investment advice. The content of this email (including any attachments) is intended solely for the addressee and access by any other person is not authorised. It may contain information which is confidential, privileged or otherwise protected from disclosure. If you are not the intended recipient of this email, (i) you should send it back to us and delete it from your system, and (ii) you are prohibited from retaining, distributing, disclosing or using (in whole or part) any of its content. Email communication may be logged and archived, monitored and/or disclosed to third parties.
CREDIT AGRICOLE CORPORATE AND INVESTMENT BANK is authorised by the Autorité de Contrôle Prudentiel et de Résolution (ACPR) and supervised by the European Central Bank (ECB), the ACPR and the Autorité des Marchés Financiers (AMF) in France and subject to limited regulation by the Financial Conduct Authority and the Prudential Regulation Authority. Details about the extent of our regulation by the Financial Conduct Authority and the Prudential Regulation Authority are available from CREDIT AGRICOLE CORPORATE AND INVESTMENT BANK London branch on request.
CREDIT AGRICOLE CORPORATE AND INVESTMENT BANK is incorporated in France with limited liability and registered in England & Wales. Registered number: FC008194. Branch No. BR 1975.  Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.
Where you have received a communication from CREDIT AGRICOLE CORPORATE AND INVESTMENT BANK this may include information which constitutes an investment recommendation as defined by the European Market Abuse Regulation (MAR).
Please see https://www.ca-cib.com/about-us/financial-information/general-disclaimer-sales-trading for important regulatory information in this regard.
If you have any questions in relation to MAR and its impact on your relationship with Credit Agricole Corporate & Investment Bank  please let your salesperson know.
Please refer to http://www.ca-cib.com/group-overview/dodd-frank-otc-derivatives.htm for any Dodd-Frank Disclosure for U.S. Persons pursuant to CFTC Regulation 23.431

You don't need to construct the hash yourself, use javascript's location.hash to access the hash fragment of the url and append it programmatically to your links.
You can shorten the setting value to var config = { state: true }; as it defaults to hash.

Is it possible to have both hash and local_storage?
From: koalyptus<EMAIL_ADDRESS>Sent: 28 July 2017 11:12
To: koalyptus/TableFilter
Cc: PANG, Wai (CA-CIB); Author
Subject: Re: [koalyptus/TableFilter] local_storage (#491)
You don't need to construct the hash yourself, use javascript's location.hash to access the hash fragment of the url and append it programmatically to your links.
You can shorten the setting value to var config = { state: true }; as it defaults to hash.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHubhttps://github.com/koalyptus/TableFilter/issues/491#issuecomment-318615342, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AWmyAoz0uBPComua3IIZAHxi0_BE5fjrks5sSbPZgaJpZM4OlUym.
Where you have received a communication from CREDIT AGRICOLE CORPORATE AND INVESTMENT BANK this may include information which constitutes an investment recommendation as defined by the European Market Abuse Regulation (MAR).
Please see http://www.ca-cib.com/group-overview/general-disclaimer-sales-trading.htm http://www.ca-cib.com/group-overview/general-disclaimer-sales-trading.htm for important regulatory information in this regard.
If you have any questions in relation to MAR and its impact on your relationship with Credit Agricole Corporate & Investment Bank  please let your salesperson know.
This email does not create a legal relationship between any member of the Crédit Agricole group and the recipient or constitute investment advice. The content of this email (including any attachments) is intended solely for the addressee and access by any other person is not authorised. It may contain information which is confidential, privileged or otherwise protected from disclosure. If you are not the intended recipient of this email, (i) you should send it back to us and delete it from your system, and (ii) you are prohibited from retaining, distributing, disclosing or using (in whole or part) any of its content. Email communication may be logged and archived, monitored and/or disclosed to third parties.
CREDIT AGRICOLE CORPORATE AND INVESTMENT BANK is authorised by the Autorité de Contrôle Prudentiel et de Résolution (ACPR) and supervised by the European Central Bank (ECB), the ACPR and the Autorité des Marchés Financiers (AMF) in France and subject to limited regulation by the Financial Conduct Authority and the Prudential Regulation Authority. Details about the extent of our regulation by the Financial Conduct Authority and the Prudential Regulation Authority are available from CREDIT AGRICOLE CORPORATE AND INVESTMENT BANK London branch on request.
CREDIT AGRICOLE CORPORATE AND INVESTMENT BANK is incorporated in France with limited liability and registered in England & Wales. Registered number: FC008194. Branch No. BR 1975.  Registered office: Broadwalk House, 5 Appold Street, London, EC2A 2DA.
Where you have received a communication from CREDIT AGRICOLE CORPORATE AND INVESTMENT BANK this may include information which constitutes an investment recommendation as defined by the European Market Abuse Regulation (MAR).
Please see https://www.ca-cib.com/about-us/financial-information/general-disclaimer-sales-trading for important regulatory information in this regard.
If you have any questions in relation to MAR and its impact on your relationship with Credit Agricole Corporate & Investment Bank  please let your salesperson know.
Please refer to http://www.ca-cib.com/group-overview/dodd-frank-otc-derivatives.htm for any Dodd-Frank Disclosure for U.S. Persons pursuant to CFTC Regulation 23.431


why Dx0nn1FelFp sheets are getting created in combined workbook.?

Hi,
I have created a flow in Power Automate to combine two different workbooks having each 1 sheet, into a single workbook containing each of the sheets.
While The flow gets succeeded, but two extra sheets get added into the Workbook named "workbooks1.Dx0nn1FelFp" and "workbook2.Dx0nn1FelFp" . How can we ignore these two sheets.
Please suggest.
Thank You,

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

ID: 688cb5b0-672f-8480-8943-6e4bc403d6b9
Version Independent ID: 61518540-2796-b66f-4bc7-aef0eca420ad
Content: Combine workbooks into a single workbook - Office Scripts
Content Source: docs/resources/samples/combine-worksheets-into-single-workbook.md
Product: excel
Technology: scripts
GitHub Login: @o365devx
Microsoft Alias: o365devx

Hi Alex,
Thank you for your reply,

No, these worksheets are coming from no where, its neither present in Original workbooks nor it was there in combined workbook before running the flow.
For Run Script 2, I have clicked Switch to input entire array button button for the worksheetInformation option. and given value as results(dynamic content) from previous step(excel run script).

The content of these additional workbook is something like this: merpalert83 : {LikelihoodValues:{},Classification:,Keyword:[]}
--83 is a number changing for each sheet, i.e. 83,84,85
Thank You,
Abinash

Thanks @AbinashBehera27. That helps narrow things down.
Have you made any changes to the sample scripts? If so, could you post your script? My thought is that the the worksheet name is getting a different value somehow. The sheet name looks like a function pointer or some other internal reference.
As a debugging step, you can also add a console.log statement to the end of the Return worksheet data script. That will make sure the worksheet name is getting exported correctly and rule out the first script as the problem area.


Related to Issue 2249: "There are references to www.dotnetnuke.com in text"

This does not (yet) resolve "There are references to www.dotnetnuke.com in text #2249", but started as a way to remove some of the superfluous mentions of dotnetnuke in the code base.
WARNING: This is my first commit/pull request, so be suspicious and feel free to ask questions! (That's also why issue #2249 is not noted in the commit message.)
Summary
The issue got me started replacing DotNetNuke with DNN through the code base - though I've yet to tackle the files actually mentioned in the issue! (I'll edit those SqlDataProvider scripts in a separate salvo in some weeks.)
I largely modified comments, updating the various copyright statements and making them consistent. I did not verify those changes with Corp legal, but they do seem common sense to me.
However I did edit some instances of old URL's, some output strings, some licenses, and assembly 'owner' fields. I believe these changes should not break any code, but they might break some tests that look for the old strings possibly. (I've not tryed rebuilding the platform as I don't know how yet.)
Thus I'd not suggest grabbing these changes until starting in on the next version - 9.4 (or 9.3.1).

Still figuring out git, as I thought this would result in a new Pull Request. Instad it merged with the previous one.
I did another Commit today that directly addresses the original issue ("References to www.dotnetnuke.com in text #2249"). I do NOT understand how the .SQLDataResource files work, so am only assuming from the issue that they needed modification.
I modified
Dnn.Platform\Website\Install\App_LocalResources\InstallWizard.aspx.resx
and hope that is enough to get the changes rippled on to the language specific files like
Dnn.Platform\Website\Install\App_LocalResources\InstallWizard.aspx.fr-FR.resx
since they are not in the source tree.
There are still a few references to Shaun Walker, but hey they can stand as far as I care!

This pull request still has conflicts with the base installation, additionally, there are a few other items needing correction, or limitation of rename.  (Ownership for example>) and additionally, the community will be moving some documentation to a new location.
I am going to close this for now, and we can revisit with 9.4.  @VashJuan we really do appreciate the contribution, the large number of file edits make the final review on this one a bit harder to manage.  Additionally the rules around copyright changes are a bit unique.  Feel free to message me with questions.


No way to get the surface scaling capabilities

get_physical_device_surface_capabilities2 Has no way to specify the p_next chain with the objects desired. Currently, the ash code implementing this functionality doesn't make use of the possibility of user-defined objects included in the p_next chain. It relies on the Default::default() implementation, which returns almost (if not the same) object as if the first version of this function:
    /// <https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/vkGetPhysicalDeviceSurfaceCapabilities2KHR.html>
    #[inline]
    pub unsafe fn get_physical_device_surface_capabilities2(
        &self,
        physical_device: vk::PhysicalDevice,
        surface_info: &vk::PhysicalDeviceSurfaceInfo2KHR,
    ) -> VkResult<vk::SurfaceCapabilities2KHR> {
        let mut surface_capabilities = Default::default();
        (self.fp.get_physical_device_surface_capabilities2_khr)(
            physical_device,
            surface_info,
            &mut surface_capabilities,
        )
        .result_with_success(surface_capabilities)
    }

I can't understand the intention behind this code, as I believe this function (get_physical_device_surface_capabilities2_khr) is intended to be used with the surface_capabilities object with something else being included in the p_next chain.
Would it make sense to rewrite this function so that it actually accepts the object from the user instead, and it becomes the user's responsibility to fill whatever is needed?
    /// <https://www.khronos.org/registry/vulkan/specs/1.3-extensions/man/html/vkGetPhysicalDeviceSurfaceCapabilities2KHR.html>
    #[inline]
    pub unsafe fn get_physical_device_surface_capabilities2(
        &self,
        physical_device: vk::PhysicalDevice,
        surface_info: &vk::PhysicalDeviceSurfaceInfo2KHR,
        surface_capabilities: &mut vk::SurfaceCapabilities2KHR,
    ) -> VkResult<vk::SurfaceCapabilities2KHR> {
        (self.fp.get_physical_device_surface_capabilities2_khr)(
            physical_device,
            surface_info,
            &mut surface_capabilities,
        )
        .result_with_success(surface_capabilities)
    }

I think I have already seen similar APIs, and how Ash handled those was okay. I think it was somewhere in the physical device properties area. I guess this particular piece would also be nice if done this way.

This was already solved (in almost the same way as proposed, except with the returned object removed because we can no longer move it; the suggestion wouldn't compile) in #744.
Unfortunately the nature of such changes is breaking, and we're not there yet to release the next breaking/major version of Ash until resolving some other big-surface-area problems. But those are taking more time than anticipated.
For the time being you could either depend on the (rev-fixed) master version of this repo to have access to the fix, or - because the implementation is so trivial - manually call the low-level function pointer by acquiring the loaded function-pointer-object via (xxx.fp().get_physical_device_surface_capabilities2_khr)(physical_device, surface_info, &mut surface_capabilities).


Diff Garden Linux Release information (SBOM) in a nice and flexible way

What would you like to be added:
With https://github.com/gardenlinux/glrd we now have a way to get actively maintained release. It would be nice to get the actual differences between releases (e.g. patch levels, ...).
We would need to have some kind of SBOM document that defines what a release contains. This might not even be definable on a release level but really on build-artefact/image level.
We already have *.release and *.manifest files that contain parts of the information but not in a "defined format".
Maybe tools like https://github.com/microsoft/sbom-tool or https://github.com/anchore/syft could be interesting to generate https://github.com/spdx compliant SBOMs.
If we would have such a SBOM document, we could build tooling to diff these documents in a nice way, e.g.

show me the differences between aws and azure builds of the latest release
show me the differences between the latest two patch levels of the latest release
...

Also the SBOM would be information that could be connected/distributed with https://github.com/gardenlinux/glvd, https://github.com/gardenlinux/glrd and https://github.com/gardenlinux/gl-oci.
Why is this needed:

transparancy
https://github.com/gardenlinux/gardenlinux/issues/2295 asks for a similar feature for the release notes
Users might want to get an idea of changes to choose their update path.

With possible changes in "builder" to generate images using buildah SBOM generation could be added to the build process. In the current code we either need to always generate an OCI archive (which is not the default), unpack the image once again to an temporary location or analyze the image tar file accepting that errors occur like [ERROR] Reading file in tar archive: absolute path for symlink destination not allowed: illegal file path: /etc/localtime for syft file:./.build/container-gardener-amd64-today-local.tar -o spdx-json=syft-sbom.json.


Openssl-1.0.2h failed compilation

Hello,
I try to cross-compile openssl-1.02h on ARM.
First, I set the environment variable:
export ARCH=arm64
export CROSS_COMPILE=aarch64-poky-linux-
Then I configured it:
./config shared --prefix=/opt/poky/aarch64-poky-linux/usr
When I do make I have the following error:
aarch64-poky-linux-gcc: error: unrecognized command line option '-m64'
: recipe for target 'cryptlib.o' failed
make[1]: *** [cryptlib.o] Error 1
make[1]: Leaving directory '/opt/poky/libssl1.0.2/openssl-1.0.2h/crypto'
Makefile:285: recipe for target 'build_crypto' failed
make: *** [build_crypto] Error 1
How can I fix this problem?

Quoting INSTALL:
       $ ./config [options]

     This guesses at your operating system (and compiler, if necessary) and
     configures OpenSSL based on this guess. Run ./config -t to see
     if it guessed correctly. If you want to use a different compiler, you
     are cross-compiling for another platform, or the ./config guess was
     wrong for other reasons, go to step 1b.


Add try_insert

Ported from https://github.com/rust-lang/rust/pull/82764.

@bors r+

:pushpin: Commit eb69bd61f333d2c291ef495b41f78ad256763b10 has been approved by Amanieu

:hourglass: Testing commit eb69bd61f333d2c291ef495b41f78ad256763b10 with merge eb9f7924c991a26e71733f04b3683cf159dd3fe3...

:broken_heart: Test failed - checks-travis

@bors r+

:pushpin: Commit 76f8cf8d9265227d5168b48d90791a781c378e24 has been approved by Amanieu

:hourglass: Testing commit 76f8cf8d9265227d5168b48d90791a781c378e24 with merge 2297523da12d53b9ca9c257442f62b9a980112a3...

:sunny: Test successful - checks-travis
Approved by: Amanieu
Pushing 2297523da12d53b9ca9c257442f62b9a980112a3 to master...


[QUESTION]: Error notification occurs when I zoom in and out the txt page.

Contact details
No response
What the essence of your question

Look at the above img for detail, as I don't understand what is happening.
Code of conduct

[X] I agree to follow this project's code of conduct

Issue policy

[X] I agree to follow this project's issue policy

This error appears because when you zoom in or out on the code, the plugin interprets this as "increase" or "decrease" the font of the code editor.
    private __mousewheelHandler = async (event: WheelEvent) => {
        if (event.ctrlKey) {
            const delta = event.deltaY > 0 ? 1 : -1;

            const next = {
                ...this.plugin.settings,
                code_editor_settings: {
                    ...this.plugin.settings.code_editor_settings,
                    font_size: this.plugin.settings.code_editor_settings.font_size += delta,
                },
            }

            await this.plugin.uptSettings(next);

            this.monacoEditor!.updateOptions({
                fontSize: this.plugin.settings.code_editor_settings.font_size,
            });

            event.stopPropagation();
        }
    }

https://github.com/Falcion/UNITADE.md/blob/5011e8f4142fa225d4f854ab2223cb389985595c/source/components/views/view_monaco.ts#L131C5-L151C6

Use the "silencing errors" mode in the additional functionality block of the plugin settings, more information about this mode:
https://github.com/Falcion/UNITADE.md/wiki/Silencing-errors
If this doesn't help, reopen this issue and I will be glad to help you!


Compressed

What was wrong?
Missing support for compressed public keys (#55).
How was it fixed?

Add to/from_compressed_bytes methods to PublicKey class.
Add implementations for the coincurve and native backend.
Add some tests.

I'm not an expert in cryptography, so please review carefully, especially the native backend code.
Cute Animal Picture

Added the suggested hypothesis test, improved the validation error message, and updated the readme.
Also, when looking at the readme I realized that the key compression API is duplicated: Once in PublicKey (where one would naturally look for it) and once in KeyAPI (where it doesn't make too much sense IMO). I therefore removed it from KeyAPI and udpated the tests accordingly.

Anything else to add today @pipermerriam ? If not, I'll merge by EOD.

I don't have write access here, can someone merge please?

Would you like a release after #58 is merged?

Thanks!

Would you like a release after #58 is merged?

Yep, that would be nice.


Redo top_qnames

Fievel only delivers the most queried domains with the count of how many times has been queried, and not which IPs are the ones that made the query.

Fixed by #66


[BUG] STRUCTs are not constructed in the class constructors

/cib

Branch 73-_BUG_STRUCTs_are_not_constructed_in_the_class_constructors created!


Implement catch and throw for Noctua's light federation protocol

Implement the catch and throw portions of Noctua's light federation protocol (see: https://github.com/geneontology/noctua/issues/403), a Galaxy-like way for applications to federate and pass data with zero knowledge of the caller.
The first use case would be able to catch from and throw back to a Noctua instance: https://github.com/geneontology/noctua/issues/403

Given that most of the Galaxy code remains in place, this would be very easy to piggyback.